открытая запись

[avva]

В комментах к этой Открытой Записи приветствуются любые темы, любые комменты, любые вопросы, любые ответы, любые дискуссии.

Давайте поговорим о чем-нибудь.

Comments

[stf-life.livejournal.com]

Подскажите мне, как программисты оценивают сроки для новой задачи и как они закладывают риск невыполнения в срок?

[clear-journal.livejournal.com]

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

Я для себя делаю это по эмпирической формуле
Время общее = Время идеальное * коэффициент оптимизма * коэффициент работоспособности системы * коэффициент говнокода * коэффициент торговли с клиентом * коэффициент идиотизма клиента

Время идеальное - Прикидываю за сколько я сделаю задачу "за один заход", то есть сяду, обдумаю, не будет никаких сюрпризов, неприятностей и меня никто дергать не будет. Увы процесс там где я работаю построен так, что мне приходится это время оценивать не глядя в код или глядя достаточно мало.

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

Коэффициент работоспособности системы - зависит от того как работают все нужные сервера и не носятся ли менеджеры по офису в поисках того кто спасет мир.

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

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

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

Вот так и получается: думаешь день, говоришь 10 дней, делаешь за 7 и то еле-еле успевая.

[stf-life.livejournal.com]

Это гениально =)

Особенно слышать это как клиенту программистов очень полезно.

[stf-life.livejournal.com]

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

[clear-journal.livejournal.com]

У нас по оценке сроков иерархия примерно такая:
программисты - теховнер - проджект менеджер

Есть продукт, над ним работают несколько программистов. Они все говорят сроки по своим кусочкам.

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

Потом теховнер и пм идут торговаться с клиентом, в результате пм оценку обычно режет (смотри коэффициент торговли), но иногда и увеличивает (например если знает что из обещанных клиенту четырех программистов этой задачей по факту заниматься будут максимум два =D).

Кто с кем торгуется: я теховнер, с другими программистами не торгуюсь, смысла в этом не вижу. Торгуются клиент с пмом и теховнером.

[stf-life.livejournal.com]

А разве любой программист может реально и полноценно тянуть роль техоунера? Ну может ему чисто кодить нравится, а разговаривать, просить, требовать, разбираться в чужом - совсем не его.

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

[clear-journal.livejournal.com]

Нет, не любой, это дело добровольное и за него доплачивают. Если теховнера не находится, найти его - головная боль пма.

Да берут и перелопачивают, что еще делать-то. Пм глубоко вздыхает и рассказывает клиентам что вот, возникли нюансы и сроки увеличились. Обычно это встречает понимание, опять же из-за специфики клиентов:
1. Со стороны клиентов нюансы тоже возникают часто
2. На внедрение системы уже потрачено уйма денег и времени. Из-за одной-другой запоздавшей доработки от нас не откажутся.

[meshko.livejournal.com]

Коротко -- плохо.

Длинно: разбивают задачу на мелкие части, прикидывают, сколько займет каждая, суммируют.

[stf-life.livejournal.com]

Я боюсь этого ответа всегда =(

[tlkh.livejournal.com]

Для той задачи над которой мы сейчас работаем, я приблизительно оценил время ее выполнения, умножил на 10 и сказал этот срок клиенту.

Просчитался в два раза.

[stf-life.livejournal.com]

А как вы оценили причину такого просчета? Почему так происходит почти у всех программистов?

[tlkh.livejournal.com]

На самом деле, бывает и когда наоборот длительность работ переоценивается. Но недооценка обычно более неприятна и на нее потому больше внимания.

В моем последнем случае, помимо недооценки сложности, у нас есть интерес сделать задачу лучше (универсальнее), чем требуется конкретному клиенту.

[stf-life.livejournal.com]

А в чем конкретно интерес? Тоесть на долгосроке вы закладываете для себя удобство программирования, чтобы потом врем не тратить? Почему бы тогда сразу не заложить это в смету и оговорить этапы?

Или тут чисто внутренняя эстетика диктует требования к коду?

[clear-journal.livejournal.com]

Интерес в том, что универсальное решение с косметическими правками можно потом продать еще кому-нибудь, да еще и не один раз

[stf-life.livejournal.com]

Вот оно что. Да, идея хорошая.

Тогда возникает еще нюанс. Когда вы находите интересные решения на сайтах, с которыми довелось работать, вы сохраняете себе эти решения "на будущее"? Или просто для себя пометку делаете, мол, вот как круто можно было сделать. И в следующий раз реализовываете и продаете.

[clear-journal.livejournal.com]

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

[tlkh.livejournal.com]

Клиент заплатил за функцию, которая будет включена в основной продукт и будет доступна всем (продукт для массового рынка; разумеется, это условие оговаривалось)

[clear-journal.livejournal.com]

Кстати да, переоценка задач тоже бывает, но клиенту что задачу переоценили ясное дело не скажут, потому что освободившимися программистами можно заткнуть другие задачи (как этого клиента, так и другого), бросить их на рефакторинг или развитие системы

[stf-life.livejournal.com]

А если задача одноразовая и клиент остается как бы разведенным на деньги. Потом ему кто-нибудь скажет, мол, вот это реально дешевле стоит, тебя кинули. Ну он в следующий раз к вам не обратится. Или это не так страшно?

[clear-journal.livejournal.com]

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