Как организован процесс работы в вашей фирме?

[ROD]

Сообщение от Utkin

Заказчик думает что он знает чего он хочет. Я был в обоих ипостасях и могу сказать что то что хочет заказчик и то что ему нужно разные вещи. И только после прямого диалога с исполнителем либо косвенное через переводчик - с системным аналитиком (эта как раз та редкая птица, которая должна быть между ТС и манагером/клиентом/начальником) может родится не просто ТЗ, а нормальное ТЗ, которе будет понятно программисту и в котором будут отражены требования заказчика. Но вот системных аналитиков маленькие фирмы не держат, поскольку не знают нафига он нужен и как он повышает эффективность работы.

Вот по этому нужно ТЗ. Пусть вам заказчик изложит "что он хочет", вы из этого сделаете некое ТЗ с тем, что заказчику "возможно нужно", согласовываете с ним, пусть заказчик внесет туда правки и подписывает. Ну а дальше... ТЗ есть ТЗ... с ним не поспорить.

[waleri]

Сообщение от Человек_Борща

Заказчик дает ТЗ => программист не любит бумажную рутину => начальник согласовывает, но не вникает => программист возмущается, что ТЗ нереальное

Что-то тут не так... ><

Начальство тут не то...

[waleri]

Сообщение от Utkin

Я представляю как заказчик сам бы план дома строителям составлял... Или министерство обороны авианосец само проектировало.

Вы не путайте ТЗ и проект. Заказчик в ТЗ пишет "Хочу 3 этажа" или "100 самолетов и скорость 35 узлов". А уже на основе требований делается проект и это уже делает не клиент а разработчик. В ТЗ написано что нам надо а в проекте уже описано как это будет сделано. Естествено, расписать для подробного расписывания ТЗ нужен специалист, но он не обязательно должен быть действуйщий программер - вполне может быть толковый менеджер.

[Человек_Борща]

Начальство тут не то...

Начальство как раз то. Зачем директору завода холодильников знать и разбираться в программировании? У него своих дел полно.

Начальство должно перенаправлять заказчика к программисту для разъяснения хотелок и перделок.

[Smitt&Wesson]

Все проекты делаются примерно так:

[ds.Dante]

По сабжу.

Если ты успел проявить себя на работе как опытный и компетентный специалист, самый правильный вариант - добиться очной ставки с нерадивым начальником и с вышестоящим начальством (генеральным директором, учредителем). Хуже увольнения всё равно ничего не грозит, а добиться правды вполне реально.

Если считаешь себя достаточно опытным и компетентным, но проявить себя на работе не получается, проще сразу уволиться, не тратя время и нервы.

Ну и третий вариант. Если опыта немного, а низкая должность и зарплата исключают чувство вины перед начальником, то можно спокойно заняться изучением новых практик и технологий, используя работу как личную лабораторию. Воистину, это будет лучший проект во всей фирме, но к последнему дедлайну он будет закончен лишь наполовину, а ты с удивлением обнаружишь предложения работы за втрое большую зарплату.

Команда, в которой я работаю, общается с заказчиком напрямую, минуя нашего менеджера проекта и директора. Последних двух товарищей мы вообще почти не замечаем - признак хорошо организованной работы. Заказчик - сами бывшие программисты, которые сейчас играют роль аналитиков.

[waleri]

Сообщение от Человек_Борща

Начальство как раз то. Зачем директору завода холодильников знать и разбираться в программировании?

Ну если в конторе только директор и разработчик, тогда наверно так. Только это несерьезная контора...

[kta87]

Хороший руководитель должен быть экономистом и маркетологом, но он так же должен знать все технические стороны производства, которым руководит, хотя бы от того, что бы оптимизация затрат производилась не только за счет сокращения кол-ва рублей в зарплате и кол-ва работников в офисе, но и за счет совершенствования тех. процесса и снижения себестоимости технологической части работ.

[Utkin]

Естествено, расписать для подробного расписывания ТЗ нужен специалист, но он не обязательно должен быть действуйщий программер - вполне может быть толковый менеджер.

Вот именно, что нужен специалист. Сам заказчик ТЗ составлять врядли станет. И я будучи заказчиком не стану этого делать (и не делал). Мне нужен сайт и точка. И если мне цвета не понравятся я все равно буду предъявлять претензии. А они мне также не понравятся по дофига причинам некотрые из которых от меня не зависят. В общем психология заказчика интересна и сложна и фигу в ее уложите в модель заказчик-->ТЗ-->программер-->бабки. И когда устойчивая позиция, что заказчик что-то вам там должен (ТЗ, еще какую замудренную муть) у программера всегда будут проблемы.

[waleri]

Это смотря какой заказчик. У серьезных организаций есть свои специалисты, которые разбираются в том что им *нужно* (и могут ни черта не понимать как это сделать) и написать что нужно.

Я не говорю, что психологию заказчика можно уложить в модель "заказчик, ТЗ, програмер", я только говорю, что эта модель много лучше, чем "заказчик, програмер". Беда в том, что не все это понимают.