Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 113
Еще иногда бывает такое, что у заказчика, есть какой то «знакомый специалист», который обязательно знает за сколько можно сделать задачу, однако при этом он не знает ни специфики работы. ни кода с которым работают. Более того, если обратились к тебе, значит он еще и написать это не может, за срок который он выставил.
То есть ты говоришь — «Я могу сделать это за 2 недели», а в ответ «А мой знакомый программист сказал, что это можно сделать за 2 дня.» И ты садишься и делаешь действительно за 2 дня. Тяпляп. Потом проходит день, бага тут бага там. И обнаруживается, что в итоге на разработку уходит не первично загаданные 2 недели, а 3 недели, т.к. то надо пофиксить старые ошибки, то тут оказывает работает не так как нужно было, и т.д.
Думаю многим знакома такая ситуация.
То есть ты говоришь — «Я могу сделать это за 2 недели», а в ответ «А мой знакомый программист сказал, что это можно сделать за 2 дня.» И ты садишься и делаешь действительно за 2 дня. Тяпляп. Потом проходит день, бага тут бага там. И обнаруживается, что в итоге на разработку уходит не первично загаданные 2 недели, а 3 недели, т.к. то надо пофиксить старые ошибки, то тут оказывает работает не так как нужно было, и т.д.
Думаю многим знакома такая ситуация.
Я бы в таких случаях отказывался бы сотрудничать с этим заказчиком. Все-таки нужно иметь минимальное самоуважение :) такие заказчики чаще всего в конечном итоге выходят боком. Я бы вообще аккуратно относился бы к любому заказчику, для которого очень критичны сроки. Мне кажется грамотный человек должен понимать, что лучше сделать не так быстро (как бог даст), но зато без нервов и не бояться, что потом софт будет полон багов, как решето. Мне по крайней мере намного удобнее работать, когда в спину не толкают. А когда толкают, то продукт получается хуже, и придется ночью просыпаться и что-то срочно фиксить :) Ну и банально неприятно, когда в твоем коде обнаруживают багу =)
Краткий курс продажи проектов:
1) Если с тобой разговаривают, значит решение еще не принято
2) Любой покупатель всегда хочет более низких цен, никто никогда тебе не скажет: «всего один день? а мой знакомый программист сказал что не менее двух недель».
3) Если у тебя спрашивают сколько будет сделать, ты спрашиваешь «а когда нужно?». Ответы типа «нужно вчера» не принимай, выясняй реальный срок\контрольную точку.
4) После выяснения срока и понимания что ты можешь\хочешь до этого срока сделать выясняй какой результат надо к сроку.
5) С пониманием срока и результата называй спокойно свой ценник. Тогда любые отмазки, вроде «А мой знакомый программист сказал, что это можно сделать за 2 дня.» уже не катят, он же не сможет сделать проект к нужному сроку.
6) Если начинает прямо говорить, что дорого, то обсудить обсудить уменьшение объема, чтобы попасть в ожидания.
7) Если сроки сжатые, то можно взять больше денег за тот же срок.
А для покупателя стратегия ровно обратная:
1) Дать меньше информации
2) Надавить по цене
3) Надавить по срокам (даже если реальной необходимости нет)
4) Бравировать статусом (если есть), типа «напишешь потом в резюме, что сделал проект для газпрома»
5) Бравировать крутостью проекта, типа «будет уникальная система, которой нет в стране\регионе\мире\вселенной».
1) Если с тобой разговаривают, значит решение еще не принято
2) Любой покупатель всегда хочет более низких цен, никто никогда тебе не скажет: «всего один день? а мой знакомый программист сказал что не менее двух недель».
3) Если у тебя спрашивают сколько будет сделать, ты спрашиваешь «а когда нужно?». Ответы типа «нужно вчера» не принимай, выясняй реальный срок\контрольную точку.
4) После выяснения срока и понимания что ты можешь\хочешь до этого срока сделать выясняй какой результат надо к сроку.
5) С пониманием срока и результата называй спокойно свой ценник. Тогда любые отмазки, вроде «А мой знакомый программист сказал, что это можно сделать за 2 дня.» уже не катят, он же не сможет сделать проект к нужному сроку.
6) Если начинает прямо говорить, что дорого, то обсудить обсудить уменьшение объема, чтобы попасть в ожидания.
7) Если сроки сжатые, то можно взять больше денег за тот же срок.
А для покупателя стратегия ровно обратная:
1) Дать меньше информации
2) Надавить по цене
3) Надавить по срокам (даже если реальной необходимости нет)
4) Бравировать статусом (если есть), типа «напишешь потом в резюме, что сделал проект для газпрома»
5) Бравировать крутостью проекта, типа «будет уникальная система, которой нет в стране\регионе\мире\вселенной».
Все так, да не совсем.
Нынешний покупатель, по крайней мере на российском рынке, не всегда хочет низких цен. Все очень сильно зависит от самого проекта. Для стартапов, например, не так важны деньги (важны, конечно, но в разумных пределах они готовы обсуждать сумму) как важны сроки. Для каких-то больших долгостроев с собственным капиталом, казалось бы, должно быть все наоборот, но это не так. Да, раньше многие кампании старались сэкономить и делать пусть подольше, но подешевле. Сейчас даже до них начинает доходить, что «подольше и подешевле» в итоге будет дороже, чем «быстрее, но дороже». Я могу детально объяснить почему так, если это кому-то интересно.
Стратегии покупателя вы, я гляжу, с потолка берете. Все совершенно не так. Пожалуй, только пункты 2 и 3 более-менее в тему, и то не всегда.
Нынешний покупатель, по крайней мере на российском рынке, не всегда хочет низких цен. Все очень сильно зависит от самого проекта. Для стартапов, например, не так важны деньги (важны, конечно, но в разумных пределах они готовы обсуждать сумму) как важны сроки. Для каких-то больших долгостроев с собственным капиталом, казалось бы, должно быть все наоборот, но это не так. Да, раньше многие кампании старались сэкономить и делать пусть подольше, но подешевле. Сейчас даже до них начинает доходить, что «подольше и подешевле» в итоге будет дороже, чем «быстрее, но дороже». Я могу детально объяснить почему так, если это кому-то интересно.
Стратегии покупателя вы, я гляжу, с потолка берете. Все совершенно не так. Пожалуй, только пункты 2 и 3 более-менее в тему, и то не всегда.
Вы оба рассуждаете с позиций программиста. А посмотрите на ситуацию с позиции бизнеса и она заиграет новыми красками. Сроки — это единственное, что реально важно заказчику. Да, бывают исключения, но очень редкие. Под конкретные даты планируется маркетинг и различные другие действия, от которых зависит взлетит идея или нет. И если вы действительно думаете, что успех продукта зависит от его качества, то вам предстоит узнать много нового. Нет, конечно, откровенно сырой продукт не будет иметь коммерческого успеха, но даже его можно сделать успешным при грамотной стратегии. А вот отсутствие результата к заданному сроку — это провал.
С другой стороны, конечно, сроки должны быть адекватными. Если заказчик настаивает на каких-то сроках, а оценщик понимает, что это будет лютый треш, нужно смело отказываться или убеждать заказчика в своей правоте. Все эти отсылки к соседу-программисту, который оценил проект в неделю, а реально там работы на два месяца, должны пресекаться еще на этапе сейлз-менеджера.
Таким образом, выпадение из сроков не может и не должно расцениваться как что-то нормальное. Это катастрофа, этого нужно избегать всеми силами. В большинстве случаев это происходит даже не из-за недооценки, т.к. оценка обычно делается с хорошим запасом, а из-за кучи других причин. И все их можно сравнительно легко устранить, если хорошенько в них разобраться.
С другой стороны, конечно, сроки должны быть адекватными. Если заказчик настаивает на каких-то сроках, а оценщик понимает, что это будет лютый треш, нужно смело отказываться или убеждать заказчика в своей правоте. Все эти отсылки к соседу-программисту, который оценил проект в неделю, а реально там работы на два месяца, должны пресекаться еще на этапе сейлз-менеджера.
Таким образом, выпадение из сроков не может и не должно расцениваться как что-то нормальное. Это катастрофа, этого нужно избегать всеми силами. В большинстве случаев это происходит даже не из-за недооценки, т.к. оценка обычно делается с хорошим запасом, а из-за кучи других причин. И все их можно сравнительно легко устранить, если хорошенько в них разобраться.
Ваш коммент полн домыслов и заблуждений. Важность сроков сильно преувеличена.
Например МС уже третий год выпускает продукты, не привязываясь к срокам релизов. Максимум что называют — в каком квартале это случится, и то, зачастую, ранее названные сроки потом двигаются. И ниче, никто не умер и не обанкротился.
Фактически для бизнеса важен не конкретный срок, а попадание в финансовый год\квартал. Иногда в публичных компаниях даже шутят, что всего есть 4 возможных срока, каждый из них совпадает с последним днем квартала. При этом, если называется срок, то он никогда не строится на оценке программистов. Ну вообще никогда.
Обычно сроки продиктованы или рыночной ситуацией (нужно выпустить версию раньше конкурентов или нужно выпустить версию, чтобы получить денег за апгрейд в следующем квартале). Реже — обещанием кого-либо из топов успеть к некоторому кварталу.
Когда этот срок попадает на уровень ПМа, то у него возникает адекватный вопрос — можно ли имеющимися ресурсами сделать такой проект к этому сроку. Он проводит оценку, по каждой задаче получает от программиста некоторое значение и строит план. Если план сходится к сроку, то менеджер хлопает в ладоши и рапортует, что успеет все сделать. В процессе оказывается, что задачи недооценены, и плохо параллелятся, а еще с прошлого проекта остался должок, который надо закрыть итп.
И вот тут есть два варианта. Первый — менеджер пойдет прессовать команду, и команда может даже уложиться в срок, потеряв очки морали и оставив технический долг, который замедлит развитие. Второй — менеджер пойдет просить сдвиг сроков\урезание фич\расширение команды (но последнее обычно не помогает). При этом менеджер получает резонный вопрос — «а заранее ты не знал?».
Понятное дело менеджеры выбирают первый вариант, ибо это сделает менеджера «эффективным», а потом появляются такие статьи, как эта. Хотя фейл со сроками 100% на совести менеджера, который не учел некоторые банальные вещи и заранее не риски.
Но прессинг сроками крайне опасен для компании. Потому что разработчики, зная что их будут прессовать, начнут раздувать оценки (никто ведь толком не сможет обосновать оценку). Это приведет к раздутию штата программистов и понижению эффективности работы. Как это не странно звучит, но именно менеджеры проектов и начальники отделов влияют на эффективность (и как следствие прибыльность) компании. А если компания разрабатывает не для себя, а продает проекты, то прессинг сроков приведет к падению продаж — стоимость проектов из-за многократного раздувания сроков вырастет и заказчику будет невыгодно такой проект покупать.
Например МС уже третий год выпускает продукты, не привязываясь к срокам релизов. Максимум что называют — в каком квартале это случится, и то, зачастую, ранее названные сроки потом двигаются. И ниче, никто не умер и не обанкротился.
Фактически для бизнеса важен не конкретный срок, а попадание в финансовый год\квартал. Иногда в публичных компаниях даже шутят, что всего есть 4 возможных срока, каждый из них совпадает с последним днем квартала. При этом, если называется срок, то он никогда не строится на оценке программистов. Ну вообще никогда.
Обычно сроки продиктованы или рыночной ситуацией (нужно выпустить версию раньше конкурентов или нужно выпустить версию, чтобы получить денег за апгрейд в следующем квартале). Реже — обещанием кого-либо из топов успеть к некоторому кварталу.
Когда этот срок попадает на уровень ПМа, то у него возникает адекватный вопрос — можно ли имеющимися ресурсами сделать такой проект к этому сроку. Он проводит оценку, по каждой задаче получает от программиста некоторое значение и строит план. Если план сходится к сроку, то менеджер хлопает в ладоши и рапортует, что успеет все сделать. В процессе оказывается, что задачи недооценены, и плохо параллелятся, а еще с прошлого проекта остался должок, который надо закрыть итп.
И вот тут есть два варианта. Первый — менеджер пойдет прессовать команду, и команда может даже уложиться в срок, потеряв очки морали и оставив технический долг, который замедлит развитие. Второй — менеджер пойдет просить сдвиг сроков\урезание фич\расширение команды (но последнее обычно не помогает). При этом менеджер получает резонный вопрос — «а заранее ты не знал?».
Понятное дело менеджеры выбирают первый вариант, ибо это сделает менеджера «эффективным», а потом появляются такие статьи, как эта. Хотя фейл со сроками 100% на совести менеджера, который не учел некоторые банальные вещи и заранее не риски.
Но прессинг сроками крайне опасен для компании. Потому что разработчики, зная что их будут прессовать, начнут раздувать оценки (никто ведь толком не сможет обосновать оценку). Это приведет к раздутию штата программистов и понижению эффективности работы. Как это не странно звучит, но именно менеджеры проектов и начальники отделов влияют на эффективность (и как следствие прибыльность) компании. А если компания разрабатывает не для себя, а продает проекты, то прессинг сроков приведет к падению продаж — стоимость проектов из-за многократного раздувания сроков вырастет и заказчику будет невыгодно такой проект покупать.
Таким образом, выпадение из сроков не может и не должно расцениваться как что-то нормальное.Если сроки названы программистами, то это нормально. А для менеджера это фейл.
Вы описываете ситуацию классического подхода к ведению проектов, который практикуется в большинстве компаний. Это не значит, что этот подход правильный, и сам факт обсуждения нужности/ненужности дедлайнов, в которые все-равно никто не укладывается очень ярко это подтверждает.
Есть и другие варианты ведения проектов, когда дедлайны не воспринимаются как карательная мера или что-то в этом духе. Когда не стоит вопрос о том, что «мы ничего не успеваем, завтра релиз», а идет спокойная планомерная работа и к оговоренному сроку готов оговоренный функционал. Это не фантастика, так реально бывает. Нужно просто поменять свои точку зрения на некоторые вещи.
А мои «домыслы и заблуждения» основаны на успешном внедрении таких подходов во вверенном мне агентстве. Менее чем за год мы сократили количество незапланированных выпадений из сроков практически до нуля, а сами сроки при этом немного уменьшились. На следующий год у нас в планах сократить сроки реализации проектов минимум в два раза. И это более чем возможно.
Есть и другие варианты ведения проектов, когда дедлайны не воспринимаются как карательная мера или что-то в этом духе. Когда не стоит вопрос о том, что «мы ничего не успеваем, завтра релиз», а идет спокойная планомерная работа и к оговоренному сроку готов оговоренный функционал. Это не фантастика, так реально бывает. Нужно просто поменять свои точку зрения на некоторые вещи.
А мои «домыслы и заблуждения» основаны на успешном внедрении таких подходов во вверенном мне агентстве. Менее чем за год мы сократили количество незапланированных выпадений из сроков практически до нуля, а сами сроки при этом немного уменьшились. На следующий год у нас в планах сократить сроки реализации проектов минимум в два раза. И это более чем возможно.
n0p, я у вас хотел спросить, а как вы боретесь с тем, чтобы сроки не были карательным инструментом в глазах программистов? Меня этот вопрос интересует. Мне покамест ничего кроме создания правильного эмоционально фона между программистами и менеджерами не приходит в голову. Подскажите, пожалуйста :)
Сроки становятся карательными в том случае, когда программист оценивает задачу (обычно еще и под давлением «быстрее говори сколько займет!»), а потом через недельку-другую ему эта задача приходит в виде тикета с заниженной оценкой. Ведь менеджер знает про подстраховку, про синдром студента и еще кучу всяких вещей, поэтому урезает оценку, чтобы программист не разбазарил время просто так. В итоге программист работает в стрессе, плюс он сильно огорчен тем, что злой менеджер урезал его оценку, а ведь он все точно и честно оценил. В итоге от обиды он может сделать задачу ровно за то время, в которое оценил, чтобы менеджер понял, что его оценка была верной. Это приводит к очевидному конфликту.
Мы же в нашей работе вообще не учитываем никакие часы и прочие бесполезные вещи. Нам важно, чтобы задача была выполнена в срок, чтобы функционал работал так, как было оговорено. Проектная команда всегда вовлечена в проект полностью, все люди в курсе отношений с клиентом, все четко знают что и когда от них ждут. Ну и плюс проектный бонус за досрочную сдачу, конечно же :)
Мы работаем по методологии Критической Цепи. Пока наша реализация не совсем правильная, мы сейчас работаем над ошибками. Но даже в таком виде она позволяет своевременно реагировать на все задержки и не распыляться между десятками задач по 8 часов и не пежить сотрудников за опоздания на некритических задачах. Ведь одна из ключевых проблем традиционного подхода в том, что менеджер следит за всеми задачами независимо от их важности для проекта в целом. Когда какая-то задача опаздывает, поднимается паника, начинаются вопросы-расспросы и мы снова возвращаемся к конфликтным ситуациям. При этом за досрочное закрытие задач никого не хвалят, потому что строго говаоря, у менеджера все запланировано так, как запланировано. Выигрыш от досрочного выполнения задач никак не учитывается. Это еще раз подтверждает постулат о том, что оценка отдельных задач не имеет ничего общего с реальными трудозатратами.
Когда каждый разработчик знает ради чего он старается и за что с него будут спрашивать, работается намного комфортнее. Я сам прошел долгий путь от младшего разработчика до технического директора, так что все эти проблемы знаю не из умных книжек, я их все на собственной шкуре ощутил :)
Мы же в нашей работе вообще не учитываем никакие часы и прочие бесполезные вещи. Нам важно, чтобы задача была выполнена в срок, чтобы функционал работал так, как было оговорено. Проектная команда всегда вовлечена в проект полностью, все люди в курсе отношений с клиентом, все четко знают что и когда от них ждут. Ну и плюс проектный бонус за досрочную сдачу, конечно же :)
Мы работаем по методологии Критической Цепи. Пока наша реализация не совсем правильная, мы сейчас работаем над ошибками. Но даже в таком виде она позволяет своевременно реагировать на все задержки и не распыляться между десятками задач по 8 часов и не пежить сотрудников за опоздания на некритических задачах. Ведь одна из ключевых проблем традиционного подхода в том, что менеджер следит за всеми задачами независимо от их важности для проекта в целом. Когда какая-то задача опаздывает, поднимается паника, начинаются вопросы-расспросы и мы снова возвращаемся к конфликтным ситуациям. При этом за досрочное закрытие задач никого не хвалят, потому что строго говаоря, у менеджера все запланировано так, как запланировано. Выигрыш от досрочного выполнения задач никак не учитывается. Это еще раз подтверждает постулат о том, что оценка отдельных задач не имеет ничего общего с реальными трудозатратами.
Когда каждый разработчик знает ради чего он старается и за что с него будут спрашивать, работается намного комфортнее. Я сам прошел долгий путь от младшего разработчика до технического директора, так что все эти проблемы знаю не из умных книжек, я их все на собственной шкуре ощутил :)
Cпасибо за ответ :) Поздравляю, я путь от от младшего разработчика до техдира еще не прошел, но уже знаю, что организовать правильные взаимоотношения между программистами и менеджерами трудно :)
Скажите, насколько определенными являются ваши задачи? Есть ли задачи исследовательского плана, когда либо вообще непонятно, как делать задачу, либо не хватает квалификации ее делать?
Как пример — кейс. Пилит команда некую систему с большим объемом данных, реляционная СУБД этот объем не тянет, и ясно (вроде бы) что решением будет использовать нереляционную, а опыта работы с такими СУБД ни у кого нет.
Или такой кейс. Нужно интегрироваться с сервисом, протокол которого досконально неизвестен. То есть, представление конечно о том как с ним общаться есть, но на практике получается, что общаться с ним нужно не совсем так, как описано в документации, а иногда — совсем не так.
Как вы с этим боретесь?
Как пример — кейс. Пилит команда некую систему с большим объемом данных, реляционная СУБД этот объем не тянет, и ясно (вроде бы) что решением будет использовать нереляционную, а опыта работы с такими СУБД ни у кого нет.
Или такой кейс. Нужно интегрироваться с сервисом, протокол которого досконально неизвестен. То есть, представление конечно о том как с ним общаться есть, но на практике получается, что общаться с ним нужно не совсем так, как описано в документации, а иногда — совсем не так.
Как вы с этим боретесь?
Конкретно мои задачи все исследовательского плана, в силу специфики должности. Но вообще у моей команды задачи бывают очень разные. Мы не беремся за все подряд проекты, а выбираем только те, которые нам интересны. Зачастую под определение интересных попадают и проекты с непонятными частями, где требуется исследование. Но соглашусь, что это редкость, т.к. основной фокус у нас смещен на другое.
Первый кейс совсем не про нас — мы разрабатываем мобильные продукты под iOS и Android, там таких задач не бывает. Второй кейс очень про нас, довольно часто клиент уже имеет в каком-то виде backend и иногда даже API, а вот с документацией все всегда очень плохо. С этим риском мы работаем очень просто — серверный модуль всегда стартует раньше всего остального, на последнем проекте мы начали его разработку еще до того как сделали UX и дизайн. В итоге к началу полномасштабной разработки приложения все риски серверного модуля сведены к минимуму, есть полное понимание что там как работает и вообще. Но да, к этому мы пришли не сразу, на паре-тройке проектов эти риски сработали и довольно хорошо нас потрепали.
Первый кейс совсем не про нас — мы разрабатываем мобильные продукты под iOS и Android, там таких задач не бывает. Второй кейс очень про нас, довольно часто клиент уже имеет в каком-то виде backend и иногда даже API, а вот с документацией все всегда очень плохо. С этим риском мы работаем очень просто — серверный модуль всегда стартует раньше всего остального, на последнем проекте мы начали его разработку еще до того как сделали UX и дизайн. В итоге к началу полномасштабной разработки приложения все риски серверного модуля сведены к минимуму, есть полное понимание что там как работает и вообще. Но да, к этому мы пришли не сразу, на паре-тройке проектов эти риски сработали и довольно хорошо нас потрепали.
Какого типа продукт и для заказчика какого типа делаете, интересно? А то создаётся впечатление, что вы и bucefal91 просто говорите про разные сектора рынка.
Кстати, да, у меня тоже сложилось такое впечатление. Как я уже отметил выше, мы разрабатываем мобильные приложения. Начиная от концепта и заканчивая релизом в сторы, полный цикл (кроме маркетинга).
Спасибо. А вот в этом:
все люди в курсе отношений с клиентом, все четко знают что и когда от них ждуткакой клиент (какого типа) имелся в виду?
Любой целевой клиент. У нас это выведено в разряд корпоративной этики: мы небольшое агентство, где все всегда в курсе последних новостей от клиента. ТЗ рождается внутри проектной команды, устав проекта доносится до всей команды на уставном собрании, мы даже проводим визуальное знакомство команды с клиентом, как минимум общее фото, а если возможно, то совместный звонок по скайпу. Это с первых дней очень сильно сближает нас с клиентом и всегда приносит положительные результаты.
Особо подчеркну, что мы работаем только с целевыми клиентами. Т.е. с такими, которые вписываются в наши критерии отбора и только когда нам интересны их проекты. За редкими исключениями можем взяться за не очень интересный проект ради стратегических целей, но в последнее время и без этих реверансов хватает работы.
Особо подчеркну, что мы работаем только с целевыми клиентами. Т.е. с такими, которые вписываются в наши критерии отбора и только когда нам интересны их проекты. За редкими исключениями можем взяться за не очень интересный проект ради стратегических целей, но в последнее время и без этих реверансов хватает работы.
«Устав проекта» — такое никогда раньше не встречал…
Это очень полезный документ, в котором зафиксированы все сроки поставок, команда проекта, ответственные лица и общая информация. Подписан директорами обеих сторон и не подлежит правке.
Умете «строить» заказчика;-)
Заказчик очень рад подписывать такой документ, т.к. он дает ему четкое понимание сроков и ответственных. Заказчик не меньше нашего заинтересован в реализации проекта точно в срок, но зачастую не имеет необходимых инструментов для контроля за процессом. Этот документ является одним из таких инструментов, которые полезны и нам и заказчику.
к оговоренному сроку готов оговоренный функционалЗначит, срок был взят с некоторым запасом. Запас использован не полностью. Возникает соблазн «сообразить головой», что «если бы больше пинали и ставили бы меньшие сроки, сделали бы быстрее». Хотя — несмотря на то, что есть, да, шанс сделать быстрее, есть и другой шанс — не сделать или сделать с техническим долгом.
Ну, МС может позволить себе выпускать продукты, не привязываясь к срокам релизов. В ситуации же, когда заказчик один и вполне определённый и требования к продукту вполне определённые, всё иначе.
Да, точно. Мне удалось в одном проекте выступать со стороны бизнеса, в другом со стороны техники. Опыт — мощнейший. И я вынес похожие мысли.
Для бизнеса критически важен срок, поскольку к нему подгоняется реклама (планируется за пару месяцев), PR, проводятся обучения, нанимаются продажники. То есть запускается «мотор», и если в срок не поставят колеса — мотор будет безвозвратно жечь бензин, снижая прибыль. Хуже — вся команда запуска проекта и продаж постепенно деморализуется, и чем дальше уходят сроки, тем хуже (пассивнее) будет старт проекта.
При этом качество продукта вторично. В принципе, на уровне ТЗ все предусмотреть нельзя. Поэтому лучше стартовать, раньше начать зарабатывать деньги и заниматься уже улучшениями/тюнингом. Я сейчас даже этой стратегии в своих личных маленьких проектах придерживаюсь: сделать базис, стартовать, потом уже мелочи делать.
Для разработчика логика другая. Хочется сделать хорошо и правильно. Но в условиях сжатых сроков начинают применяться неоптимальные алгоритмы, и часто «прибитые гвоздями». Главное — быстрее сделать базис, который нормально должен работать.
А тут заказчик приходит с маркетологом, и начинают говорить: «а давай такую плюшку сделаем?». То, что еще базис не работает как надо, и эта плюшка — изменение ТЗ и ломка графика, это же заказчика не волнует?
Вот и получается, что следствием deadline является:
1. Некачественный продукт (при попустительстве заказчика)
2. Более-менее вылизанный базис продукта, но прибитый гвоздями
3. Кое-как прилепленные «на коленке» плюшки заказчика (часто вне бизнес-анализа и архитектуры)
4. Демотивация разработчиков (продукт плохой, невовремя, плюс еще «через коленку» заставляют плюшки лепить.
Но… без deadline нельзя, см. начало моего сообщения. :)
Пат!
Для бизнеса критически важен срок, поскольку к нему подгоняется реклама (планируется за пару месяцев), PR, проводятся обучения, нанимаются продажники. То есть запускается «мотор», и если в срок не поставят колеса — мотор будет безвозвратно жечь бензин, снижая прибыль. Хуже — вся команда запуска проекта и продаж постепенно деморализуется, и чем дальше уходят сроки, тем хуже (пассивнее) будет старт проекта.
При этом качество продукта вторично. В принципе, на уровне ТЗ все предусмотреть нельзя. Поэтому лучше стартовать, раньше начать зарабатывать деньги и заниматься уже улучшениями/тюнингом. Я сейчас даже этой стратегии в своих личных маленьких проектах придерживаюсь: сделать базис, стартовать, потом уже мелочи делать.
Для разработчика логика другая. Хочется сделать хорошо и правильно. Но в условиях сжатых сроков начинают применяться неоптимальные алгоритмы, и часто «прибитые гвоздями». Главное — быстрее сделать базис, который нормально должен работать.
А тут заказчик приходит с маркетологом, и начинают говорить: «а давай такую плюшку сделаем?». То, что еще базис не работает как надо, и эта плюшка — изменение ТЗ и ломка графика, это же заказчика не волнует?
Вот и получается, что следствием deadline является:
1. Некачественный продукт (при попустительстве заказчика)
2. Более-менее вылизанный базис продукта, но прибитый гвоздями
3. Кое-как прилепленные «на коленке» плюшки заказчика (часто вне бизнес-анализа и архитектуры)
4. Демотивация разработчиков (продукт плохой, невовремя, плюс еще «через коленку» заставляют плюшки лепить.
Но… без deadline нельзя, см. начало моего сообщения. :)
Пат!
Ситуация патовая, но мне кажется, что если:
то хотя бы такой патовой ситуации можно избегать (хотя у меня получилось очень много «если») :) Мне кажется, что если все работают на совесть и хорошо срабатываются, то пата все-таки не будет :)
- заказчик адекватный (не переделывает все на полпути и понимает, что сроки — это лишь оценка). Заказчику полезно более-менее подстраховаться на случай маленькой задержки по отношению к срокам. А если задержка получилась немаленькой, то о ее появлении будет известно не в день дедлайна, и тогда у заказчика будет время на какие-то манервы. Заказчик может винить во всем исполнителей, а может занимать про-активную позицию и понимать, что люди ошибаются, и пытаться минимизировать последствия ошибок других людей. Пускай он в этих ошибках и не виноват, но раз на кону его бизнес, то я бы не тыкал пальцами в других, а сообща пытался бы спасать ситуацию.
- менеджер правильно себя ведет — запрашивает четкие требования, обсуждает потенциальные фичи с заказчиком (часто заказчиков можно уговаривать на какие-то более адекватные фичи в функционале). Более адекватные фичи более легко ложатся на архитектуру. Здесь я не «втюхивать» имел ввиду, а именно занимать активную позицию в обсуждении будущего функционала. Часто здравым смыслом можно додуматься что в таком-то месте просится такая-то фича; или по лицу заказчика видно, что он скоро будет просить что-то новое в такой-то части проекта. Менеджер должен улавливать все эти вещи и сообщать программистам, чтобы ребята имели максимум информации.
- программист себя правильно ведет: закладывает архитектуру в 2 раза шире и гибче, чем то, что от него просят сейчас. Смело заявляет «вот эту плюшку можно сделать за +7 дней или гвоздями прикручивать» — и пускай менеджер/заказчик решают им нужна краткосрочная выгода или долгосрочная
то хотя бы такой патовой ситуации можно избегать (хотя у меня получилось очень много «если») :) Мне кажется, что если все работают на совесть и хорошо срабатываются, то пата все-таки не будет :)
Действительно, слишком много «если». а по поводу адекватности заказчика, то здесь есть вот какое наблюдение.
1. Если (ох уж эти «если») мы говорим про стартап — то есть важный момент — заказчик и владелец — одно лицо, то понятие «работать на совесть» имеет место быть.
2. Но если компания чуть больше, и есть владелец, есть генеральный, а есть менеджер проекта (он же заказчик), то все становится интереснее.
а) менеджер проекта не заинтересован показывать свою некомпетентность перед генеральным. Если он видит, что ТЗ неполное, ему проще надавать на подрядчика-разработчика, чем признать, что что-то забыл, а если видит срыв по срокам, то он будет жестко давить на подрядчика с криками «твои проблемы», одновременно говоря генеральному — «да они у… не умеют работать, и срывают сроки».
б) Генеральный уже пообещал по пьяни или в бане акционеру: «Михалыч, ты че, меня не знаешь? Все организую, все будет четко и в срок — у меня же классная команда». Теперь ему легче депремировать менеджера проекта, наорать на него, и пообещать уволить. Разве может генеральный признаться владельцу, что он не умеет управлять процессом или нанимать тех людей, которые могут качественно управлять процессом.
в) Владелец… вот он как раз и заинтересован работать на совесть, и легко может сроки перенести, и о качестве подумать… но как к нему доберется подрядчик через фильтры а) и б)? :)
1. Если (ох уж эти «если») мы говорим про стартап — то есть важный момент — заказчик и владелец — одно лицо, то понятие «работать на совесть» имеет место быть.
2. Но если компания чуть больше, и есть владелец, есть генеральный, а есть менеджер проекта (он же заказчик), то все становится интереснее.
а) менеджер проекта не заинтересован показывать свою некомпетентность перед генеральным. Если он видит, что ТЗ неполное, ему проще надавать на подрядчика-разработчика, чем признать, что что-то забыл, а если видит срыв по срокам, то он будет жестко давить на подрядчика с криками «твои проблемы», одновременно говоря генеральному — «да они у… не умеют работать, и срывают сроки».
б) Генеральный уже пообещал по пьяни или в бане акционеру: «Михалыч, ты че, меня не знаешь? Все организую, все будет четко и в срок — у меня же классная команда». Теперь ему легче депремировать менеджера проекта, наорать на него, и пообещать уволить. Разве может генеральный признаться владельцу, что он не умеет управлять процессом или нанимать тех людей, которые могут качественно управлять процессом.
в) Владелец… вот он как раз и заинтересован работать на совесть, и легко может сроки перенести, и о качестве подумать… но как к нему доберется подрядчик через фильтры а) и б)? :)
Нет, даже в этом случае ситуация не изменится ни на грамм, т.к. Корневая проблема никуда не денется.
Но ведь на самом деле причина всех описанных проблем не в наличии дедлайна. Если бы не существовало ограничения срока, проблемы были бы все те же самые, но дополнительно еще продукт никогда бы не зарелизился. Проблема в управлении проектом и в подходах к разработке, но никак не в наличии дедлайна.
Deadline должен быть — без сомнения. Но deadline бывает разный. Бывает — определенный подрядчиком, и принятый заказчиком. А бывает — навязанный заказчиком, который по ходу меняет ТЗ, который «играет» в политику с вышестоящим руководством. И тогда, в большей степени, именно deadline является проблемой — потому что именно он демотивирует команду, что раскручивает маховик рисков с еще большей силой.
От очень жестких дедлайнов никуда не убежишь когда речь идет о продуктивных системах компании и фич, связанных с изменениями законодательства, изменению договорных условий или изменений политики компании.
Естественно, данные проекты сдвигают сроки остальных перспективных разработок.
Естественно, данные проекты сдвигают сроки остальных перспективных разработок.
«Под давлением — растут алмазы». Не помню кто сказал. Мозг устроен так, что лучшие результаты он выдает под давлением различных ограничений. Абзац про «спасать ситуацию» отличный, и также подошел бы к статье — «Как сделать, чтобы программистов не угнетали сроки».
Я полностью согласен, что «под давлением растут алмазы». Но это изматывает программистов. И в какой-то день измотанный и эмоционально разбитый программист просто уйдет в другое место. Я почему-то считаю, что работа — это не смысл жизни, а лишь способ выживания (зарабатывания денег). И мне кажется, что все-таки правильно относится к работее чуть расслабленнее, чем «под давлением растут алмазы» :)
Под давлением растут технические алмазы. А шедевры, которые потом превращают в бриллианты, вырастают в естественных условиях. Так что — смотря что за продукт ожидается.
Интересно, под давлением каких обстоятельств, по мнению автора этой фразы, выращивался такой алмаз, как «Джоконда»…
Один мой знакомый говорил: «Развитие возможно только в условиях ограничений». :)
Наверное, описанная проблема относится не только к софту. Это просто проблема «как оценить работу, если я такого не делал никогда?»
И есть к этому подходы: вместо того, чтобы сразу же давать оценку и потом стрессовать, лучше ответить так: «мне нужно X дней на то чтобы оценить размер работ». За это время разбить задачу на под-задачи и поискать инфу по каждой из них (коллеги, инет, и т.д.).
На пассажи типа «мне сказали, что это 2 дня работы» спокойно говорить: «если они могут за 2, то пусть делают. Я не могу взять на себя ответственность отвечать за их оценки. Пока я сам не оценю размер работ, я не смогу дать обещаний. Более того: время затраченное мной на подготовку наверняка позволит потратить меньше на реализацию.»
со временем (опытом) вы будете получать всё больше типовых заданий, которые уже были сделаны вами раньше, и сможете точно оценивать сроки без подготовки
И есть к этому подходы: вместо того, чтобы сразу же давать оценку и потом стрессовать, лучше ответить так: «мне нужно X дней на то чтобы оценить размер работ». За это время разбить задачу на под-задачи и поискать инфу по каждой из них (коллеги, инет, и т.д.).
На пассажи типа «мне сказали, что это 2 дня работы» спокойно говорить: «если они могут за 2, то пусть делают. Я не могу взять на себя ответственность отвечать за их оценки. Пока я сам не оценю размер работ, я не смогу дать обещаний. Более того: время затраченное мной на подготовку наверняка позволит потратить меньше на реализацию.»
со временем (опытом) вы будете получать всё больше типовых заданий, которые уже были сделаны вами раньше, и сможете точно оценивать сроки без подготовки
Правильно. Я тоже уже отвечаю «дайте мне 3-4 часа», когда у меня спрашивают о сроках, а то с потолка отвечать их я уже замордовался. Но какими бы умными программистами мы не были, мы всегда будем ошибаться в своих сроках. И в статье я как раз хотел показать, что сроки не должны быть какими-то железными рамками, а всего лишь ориентиром. В противном случае продуктивность программиста будет снижаться, по моему впечатлению.
По-существу верно, но бывают ситуации, когда оценку надо дать вот прямо сейчас, не сходя с этого места. И тут в дело вступает интуиция, которая появляется исключительно только с опытом.
Декомпозиция задачи иногда может завести нас не туда, особенно с новыми неизвестными задачами. Например, если у задачи есть несколько вариантов решения, то при попытке декомпозиции мы можем сразу выбрать не самый эффективный вариант. В моей практике такое бывало, и довольно часто. Обычно в таких случаях я и моя команда полагаемся на интуицию и 5-10 минут штурма, чтобы понять в какие адекватные сроки можно будет получить хороший результат. Как правило у заказчика уже есть представление о том, когда ему нужна фича или продукт. Задача команды — суметь договориться с заказчиком о том, какой конкретно функционал его к этой дате устроит.
При таком подходе недовольных с обеих сторон становится гораздо меньше.
Декомпозиция задачи иногда может завести нас не туда, особенно с новыми неизвестными задачами. Например, если у задачи есть несколько вариантов решения, то при попытке декомпозиции мы можем сразу выбрать не самый эффективный вариант. В моей практике такое бывало, и довольно часто. Обычно в таких случаях я и моя команда полагаемся на интуицию и 5-10 минут штурма, чтобы понять в какие адекватные сроки можно будет получить хороший результат. Как правило у заказчика уже есть представление о том, когда ему нужна фича или продукт. Задача команды — суметь договориться с заказчиком о том, какой конкретно функционал его к этой дате устроит.
При таком подходе недовольных с обеих сторон становится гораздо меньше.
Немного около темы. Есть разные проекты — есть и такие, у которых дату завершения сдвинуть нельзя. Как и всё остальное, выбор «успевать или не успевать в конкретную дату» должен разрешаться соотношением потерь и выгод. То есть если мы опоздаем на неделю с предновогодней акцией это одно, а если мы собственный продукт подпилим еще на неделю дольше — другое.
А вообще, вот так если повспоминать сколько было попыток отвязать или хотя бы стандартизировать оценку. По памяти, был какой-то ГОСТ, который предписывал по странице ТЗ в день реализовывать абстрактному землекопу в вакууме. ТЗ, естественно, тоже должно быть по ГОСТ. Еще метод функциональных точек — который по своей трудозатратности может полпроекта наверное занимать.
В целом же думаю, что дедлайны в разработке софта бесполезны, сокращение сроков можно (и нужно) мотивировать, но сроки при этом ограничивать бесполезно (при заданном скажем, качестве). Не потому что «мы все живые люди» — я не гуманист какой-нибудь, а потому что суммарные характеристики сложно в деталях устроенной (и еще несуществующей) системы можно оценивать только вероятностно. Если нужна более точная оценка, то можно проводить эксперимент (сделать прототип), неопределенность будет ниже, но не исчезнет. И только факт скажет, насколько метод прогнозирования был хорош и он соответствовал модели конечной системы. Таким образом, совершенствовать надо усилия по оценке, а всякий дедлайно-микроменеджмент приводит в итоге к расшатыванию всех систем (и коллектива, и продукта), так как есть усиливающая обратная связь между качеством результата и успешностью проектов разработки.
Возвращаясь к ситуации с софтом для предновогодней акции: тот кто хочет успеть, должен принимать не только финансовый, но и моральный так сказать риск на себя, а не перекладывать его на программистов или даже менеджера.
А вообще, вот так если повспоминать сколько было попыток отвязать или хотя бы стандартизировать оценку. По памяти, был какой-то ГОСТ, который предписывал по странице ТЗ в день реализовывать абстрактному землекопу в вакууме. ТЗ, естественно, тоже должно быть по ГОСТ. Еще метод функциональных точек — который по своей трудозатратности может полпроекта наверное занимать.
В целом же думаю, что дедлайны в разработке софта бесполезны, сокращение сроков можно (и нужно) мотивировать, но сроки при этом ограничивать бесполезно (при заданном скажем, качестве). Не потому что «мы все живые люди» — я не гуманист какой-нибудь, а потому что суммарные характеристики сложно в деталях устроенной (и еще несуществующей) системы можно оценивать только вероятностно. Если нужна более точная оценка, то можно проводить эксперимент (сделать прототип), неопределенность будет ниже, но не исчезнет. И только факт скажет, насколько метод прогнозирования был хорош и он соответствовал модели конечной системы. Таким образом, совершенствовать надо усилия по оценке, а всякий дедлайно-микроменеджмент приводит в итоге к расшатыванию всех систем (и коллектива, и продукта), так как есть усиливающая обратная связь между качеством результата и успешностью проектов разработки.
Возвращаясь к ситуации с софтом для предновогодней акции: тот кто хочет успеть, должен принимать не только финансовый, но и моральный так сказать риск на себя, а не перекладывать его на программистов или даже менеджера.
Спасибо за комментарий. Особенно мне понправился ваш последний абазц. Именно, программисты не виноваты в том, что они неправильно оценили сроки. И да, дедлайно-микроменеджмент (как вы это очень точно назвали) чаще всего приводит к угнетации программистов. Есть ленивые программисты — их нужно всегда подгонять и микроменеджить (наверное, я ленивых программистов еще не видел). А хорошие квалицированные программисты, как правило, самомотивируются на продуктивную работу только потому, что им интересно программить. И тогда менеджер превращается в этого страшного монтсра, которого программисты хотят пересекаться как можно меньше. Им код писать куда интереснее, чем каждый день рассказывать о том, что сегодня фичу написать не успели, но что завтра есть шансы ее закончить.
Я уже побывал в обоих шкурах и программиста, и менеджера. И по крайней мере по отзывам своих подопечных программистов, я — не этот менеджер-монстр :) Вроде бы банальные вещи, которые очень просто можно на бумаге расписать, а действительно хорошего менеджера, с пониманием всех этих вещей, я еще не видел :(
Я уже побывал в обоих шкурах и программиста, и менеджера. И по крайней мере по отзывам своих подопечных программистов, я — не этот менеджер-монстр :) Вроде бы банальные вещи, которые очень просто можно на бумаге расписать, а действительно хорошего менеджера, с пониманием всех этих вещей, я еще не видел :(
Я вообще-то несколько другую мысль хотел высказать :) Что сроки в ИТ-проектах нужны (всем наверное, и даже разработчикам, чтобы быть в тонусе) — но они результаты моделирования, и относится к ним надо как к модельным данным. Детерминированные модели плохи тем, что они создают иллюзию гарантии, модели с отказом от оценок (некоторые из agile) — плохи тем, что не нужны бизнесу, которому необходимы и сроки и бюджет, проблема вероятностных — их язык тоже бизнесу не всегда понятен. Выход я вижу в том, чтобы совершенствовать вероятностные модели до такой степени, чтобы они могли какой-то гарантированный интервал и мат. ожидание выдавать, и количественные оценки рисков. Не сказать, что этого не существует. Даже в банальном MS Project есть оценка по трем точкам, а в каком-нибудь Spider Project можно даже увидеть кривую кумулятивной вероятности. Вот только на практике мы этого всего не видим, вот в чем моя печаль.
Я наверное из-за ограниченности своих знаний в управлении проектов вас неправильно понял. :) Я из этих 2 комментариев много новых слов прочитал об управлении проектов. Я посмотрел на ваши публикации здесь на хабре — вижу, что вас эта тема очень интересует. Я покамест все-таки дилетант в области управления проектов и в основном опираюсь на интуицию и чувство правильности. Обязательно почитаю ваши публикации, надеюсь узнать много нового и полезного :)
Ну и дай бог, чтобы побольше людей так же серьезно относились к оценки сроков и трудоемкости, как вы :)
Ну и дай бог, чтобы побольше людей так же серьезно относились к оценки сроков и трудоемкости, как вы :)
Я-то ладно. Я сейчас уже не ПМ, разработчик обратно — по обстоятельствам тех мест, в которых нахожусь. Не суть. Очень рекомендую, если тема оценки интересна — авторитетного Макконнела, и книгу "Сколько стоит программный проект". Я на Хабре не в первый раз её рекомендую, просто она очень хороша.
Спасибо, прочитаю :) Я уже успел прочитать вашу habrahabr.ru/post/150145/ — я как раз нахожусь на этапе планирования и экономической оценки одной своей идеи. Интересно :) Может быть я не настолько серьезно настроен, но статья вызвала небольшое ощущение overkill :) Может для маленьких затей удобнее все это практикой проверять? Я безусловно оцениваю размер своего сегмента в рынке, оцениваю сколько они готовы платить за продукт, оцениваю себестоимость создания продукта и его маркетинга, но в более кустарном варианте, без четких схем и детерминированных руководств.
Я скорее руководствовался мыслью оценить, сколько денег нужно ежемесячно на поддержание моей идеи. После этого я хочу попытаться найти Х клиентов под идею. Если Х клиентов * Y долларов (средний чек) > ежемесячные затраты на поддержку сервиса — то можно делать. Это в очень упрощенном варианте конечно. Здесь я не учитываю первоначальную инвестицию, вопросы маркетинга и % конвертации лидов в пользователей. Но я где-то такой схемой думал руководствоваться для себя.
С этими формулами экономической отдачи запуститься, а потом уже пускай сами пользователи мной руководят — хотят такие-то фичи — буду делать им такие-то фичи. Болтаясь более менее на плаву, я смогу уже практикой проверить успешность разных статегий маркетинга и дальше уже экспериментальным путем искать правильное направление развития. Все-таки практика, как ни крути, всегда отличается от теории.
Я скорее руководствовался мыслью оценить, сколько денег нужно ежемесячно на поддержание моей идеи. После этого я хочу попытаться найти Х клиентов под идею. Если Х клиентов * Y долларов (средний чек) > ежемесячные затраты на поддержку сервиса — то можно делать. Это в очень упрощенном варианте конечно. Здесь я не учитываю первоначальную инвестицию, вопросы маркетинга и % конвертации лидов в пользователей. Но я где-то такой схемой думал руководствоваться для себя.
С этими формулами экономической отдачи запуститься, а потом уже пускай сами пользователи мной руководят — хотят такие-то фичи — буду делать им такие-то фичи. Болтаясь более менее на плаву, я смогу уже практикой проверить успешность разных статегий маркетинга и дальше уже экспериментальным путем искать правильное направление развития. Все-таки практика, как ни крути, всегда отличается от теории.
Это не теория от практики отличается, потому что это не теория, а моделирование. Модели от практики могут отличаться. Если вы стартапер и в любой момент можете прекратить проект, или отпивотиться — это одно. Если вы компания, которая выпускает N продуктов посредством f(N) > N проектов, то тут то, что я описывал — необходимо. Хотя и в вашем случае моделирование не лишее — во-первых, подобными же доходными методами, что описан, оценивается стоимость, во-вторых, отсутствие учета инвестиций может оставить без штанов далеко не только на бумаге, никакие пивоты не помогут. Это одна из основных мыслей того поста, что накопленная положительная маржа по операциям должна как можно скорее отбивать инвестиции — это если хочется заработать. Учет стоимости капитала уже нужен, когда есть альтернативные вложения.
Если всё что я написал — overkill, а стратегия «ввязаться в драку, а там видно будет» — fun, то что ж, лишать удовольствия не буду :) Просто избегайте тогда участия формальных инвесторов, пока не окупитесь. А то я видал, как через суды инвесторы забирали обратно и технику и деньги, оставляя стартаперов с минусами.
Если всё что я написал — overkill, а стратегия «ввязаться в драку, а там видно будет» — fun, то что ж, лишать удовольствия не буду :) Просто избегайте тогда участия формальных инвесторов, пока не окупитесь. А то я видал, как через суды инвесторы забирали обратно и технику и деньги, оставляя стартаперов с минусами.
Согласен с вашим комментарием в части ошибочности оценочного подхода. Нам в свое время пришлось много грабель с этим вопросом собрать, прежде чем пришло озарение.
Фокус в том, что сами по себе оценки задач не имеют смысла в силу наличия рисков и неопределенностей. Особенно мало смысла в оценках микрозадач «менее 8 часов». Мы такой подход пробовали, он с треском провалился. В итоге пришли к пониманию, что не так важно сколько времени потрачено на ту или иную задачу, ведь важен конечный результат, а не процесс. Следовательно, смысл имеет оценивать именно функционал, который может быть готов к определенному сроку. Клиент хочет видеть прогресс, регулярно — планируем даты показов и оцениваем какие фичи мы сможем в эти даты продемонстрировать, при этом не лопнув от нагрузки. Чем крупнее блоки функционала, тем больше места для маневра, тем проще менеджеру держать все под контролем. При использовании такого подхода совместно с любой гибкой методологией (да даже с водопадом худо-бедно работает!) можно получить очень крутые результаты.
Фокус в том, что сами по себе оценки задач не имеют смысла в силу наличия рисков и неопределенностей. Особенно мало смысла в оценках микрозадач «менее 8 часов». Мы такой подход пробовали, он с треском провалился. В итоге пришли к пониманию, что не так важно сколько времени потрачено на ту или иную задачу, ведь важен конечный результат, а не процесс. Следовательно, смысл имеет оценивать именно функционал, который может быть готов к определенному сроку. Клиент хочет видеть прогресс, регулярно — планируем даты показов и оцениваем какие фичи мы сможем в эти даты продемонстрировать, при этом не лопнув от нагрузки. Чем крупнее блоки функционала, тем больше места для маневра, тем проще менеджеру держать все под контролем. При использовании такого подхода совместно с любой гибкой методологией (да даже с водопадом худо-бедно работает!) можно получить очень крутые результаты.
:) Удивительно, что вы еще не собрали стопку ответов от здешних менеджеров о том, что делать любую вещь без сроков — это самоубийство. Сроки очень сильно помогают в планировании, оценки трудоемкости и оценки финансовых затрат на выполнение фичи.
Представьте, что вам нужно построить забор. Его можно построить из дерева и из бетона. У вас есть 100 уе и 3 дня на то, чтобы сделать забор. Какой забор вы будете делать?) А если вы оцените сроки и себестоимость каждого из заборов, то вам уже проще будет принять решение, какой забор делать :)
Представьте, что вам нужно построить забор. Его можно построить из дерева и из бетона. У вас есть 100 уе и 3 дня на то, чтобы сделать забор. Какой забор вы будете делать?) А если вы оцените сроки и себестоимость каждого из заборов, то вам уже проще будет принять решение, какой забор делать :)
Да, никто не предвидит сразу все риски. Чем чаще в прошлом вы строили забор, тем больше шансов, что вы будете знать о всех рисках. И я как раз пытался в статье высказать мысль, что нужно понимать, что любая оценка сроков — это всего лишь оценка, а не 100% гарантия (как многие воспринимают сроки). На базе этих оценок можно оценивать количество сделанной работы через месяц. Имея оценочное количество фич в проекте через месяц, можно адаптировать маркетинг, финансы и прочее под эти данные. Только опять же, нужно четко понимать, что это всего лишь оценка, и что на деле может получиться по-другому. Я все-таки считаю, что сроки помогают с планированием, и что планирования — это полезная штуковина.
В целом-то верно, что никакая оценка не даст 100% гарантию. В этом парадокс оценок, что даже имея заранее заложенный запас в 200% никто не застрахован от промаха. И более того, вероятность такого промаха очень высока. Потому я считаю, что оценки в часах вообще не нужны, они не дают никакой полезной информации, только мешают.
Но с другой стороны, нужно как-то оценивать сроки реализации и стоимость работы. С этим ведь нет противоречий? Вы не сможете ни одному клиенту сказать: «ну эта фича займет у нас хз сколько времени и будет стоить вам хз сколько денег». А для того, чтобы назвать эти два параметра, нужно делать оценку, как ни крути.
Но с другой стороны, нужно как-то оценивать сроки реализации и стоимость работы. С этим ведь нет противоречий? Вы не сможете ни одному клиенту сказать: «ну эта фича займет у нас хз сколько времени и будет стоить вам хз сколько денег». А для того, чтобы назвать эти два параметра, нужно делать оценку, как ни крути.
Так а как тогда оценивать сроки? Вы вроде сказали, что в часах оценивать неудобно, но тоже сказали, что все-таки оценивать нужно. Направшивается тогда мой вопрос =)
Тут скорее интуитивная оценка, нежели какая-то математика. Мы стараемся плясать от ожиданий клиента. Стоит оговориться, что клиенты, которым «нужно очень срочно, прямо вчера» к нам вообще не попадают, мы с такими просто не работаем, ни за какие деньги. Адекватные клиенты адекватно называют сроки, когда конкретно им нужна фича или продукт и почему. Вот это «почему» очень важно. Если срок обусловлен просто желанием, мы работаем с клиентом в ключе выбора более разумного срока. Не всегда позже, иногда предлагаем сделать раньше, чтобы не создавать простои на пустом месте. Если срок обусловлен более серьезными мотивами, например, маркетинговой кампанией, то все гораздо проще — нужно понять реально ли вообще в этот срок уложиться и что для этого нужно сделать. Оценка производится исходя из количества обязательного функционала и его сложности. И если с количеством никогда ни у кого вопросов не возникает, то со сложностью как раз проблемы и вылезают. Все программисты всегда приуменьшают сложность задачи или недооценивают ее важность для проекта. Еще распространенная проблема — оценка задачи в отрыве от остальных задач. Собственно, поэтому почасовая оценка и не имеет смысла.
Так что, как это ни странно звучит, но мы руководствуемся в оценке своей экспертизой и интуицией. И то и другое нарабатывается с опытом, так что с каждым разом точность оценки сроков только увеличивается. Дополнительная оценка сложности функционала позволяет называть реальную цену, не привязываясь к почасовому рейту (т.к. у нас просто нет почасового рейта). В итоге клиенты остаются довольны и сроками и ценой, а своевременное выполнение взятых на себя обязательств с нашей стороны делает их по-настоящему счастливыми.
Так что, как это ни странно звучит, но мы руководствуемся в оценке своей экспертизой и интуицией. И то и другое нарабатывается с опытом, так что с каждым разом точность оценки сроков только увеличивается. Дополнительная оценка сложности функционала позволяет называть реальную цену, не привязываясь к почасовому рейту (т.к. у нас просто нет почасового рейта). В итоге клиенты остаются довольны и сроками и ценой, а своевременное выполнение взятых на себя обязательств с нашей стороны делает их по-настоящему счастливыми.
Понятно :) Мне явно пошло на пользу написать эту статью и прочитать все комментарии. Буду стараться качать свой навык оценки сроков. У меня на работе к этому относительно расхлябано относятся, но я попробую исправить ситуацию в лучшую сторону. Похоже, что у каждого формируется свой собственный подход: кто-то интуицией работает, кто-то считает часы и домножает на 2 или на 3, а кто-то используют какую-то детерменированную математику для расчета.
Очень вас поддерживаю в плане «клиентов, которым нужно прямо вчера» — нужно их воспитывать, а то и себе нервы портят и другим людям.
Очень вас поддерживаю в плане «клиентов, которым нужно прямо вчера» — нужно их воспитывать, а то и себе нервы портят и другим людям.
1. Автор, не в обиду вам, статья очень расплывчатая. Видимо тема вас успела затронуть и потрепать, но подход к вопросу еще не кристаллизовался.
2. Сроки должны быть, в любом случае. Иначе результата не будет никогда.Sad but true.
3. Пару раз попав на собственных оптимистичных оценках программист к сожалению не начинает лучше оценивать и лучше работать — он начинает умножать свое первое представление на два, на три, на десять.
4. Менеджер должен не просто стрясти оценку с разработчика, но и потребовать обоснования срока, тем самым проконтролировав что оценка взята не с потолка. Разработчика же такой подход заставит подойти к оценке более ответственно.
5. Да, если вы договорились что будет готов через две недели — значит через неделю уже должна быть демонстрация полностью работающей фичи. Еще неделю будете править и тестировать.
6. Менеджер должен иметь собственный deadline, на 10-30% позже программерского.
7. Если назвал срок — пожалуйста за него отвечай, иначе это детский сад. Не можешь назвать — так и скажи, слишком велика неопределенность, или назови вилку, или оценку сверху. На угрозы и давление — pocker face.
8. Неопытные менеджеры любят поторговаться по срокам и запрессовать разработчика, думая что классно провели переговоры. Это может стать фатальной ошибкой. Или потеряете в качестве, или в мотивации или сроки все равно профакапят.
9. Есть другая альтернатива. Менеджер называет срок, и спрашивает — «как можно решить эту задачу за такой срок»? Т.е. разработчик еще не подписался, но начинает уже продумывать варианты, мыслить творчески. Иногда гениальные идеи приходят.
2. Сроки должны быть, в любом случае. Иначе результата не будет никогда.Sad but true.
3. Пару раз попав на собственных оптимистичных оценках программист к сожалению не начинает лучше оценивать и лучше работать — он начинает умножать свое первое представление на два, на три, на десять.
4. Менеджер должен не просто стрясти оценку с разработчика, но и потребовать обоснования срока, тем самым проконтролировав что оценка взята не с потолка. Разработчика же такой подход заставит подойти к оценке более ответственно.
5. Да, если вы договорились что будет готов через две недели — значит через неделю уже должна быть демонстрация полностью работающей фичи. Еще неделю будете править и тестировать.
6. Менеджер должен иметь собственный deadline, на 10-30% позже программерского.
7. Если назвал срок — пожалуйста за него отвечай, иначе это детский сад. Не можешь назвать — так и скажи, слишком велика неопределенность, или назови вилку, или оценку сверху. На угрозы и давление — pocker face.
8. Неопытные менеджеры любят поторговаться по срокам и запрессовать разработчика, думая что классно провели переговоры. Это может стать фатальной ошибкой. Или потеряете в качестве, или в мотивации или сроки все равно профакапят.
9. Есть другая альтернатива. Менеджер называет срок, и спрашивает — «как можно решить эту задачу за такой срок»? Т.е. разработчик еще не подписался, но начинает уже продумывать варианты, мыслить творчески. Иногда гениальные идеи приходят.
Спасибо за комментарий. Трудно не согласиться с любым из пунктов. Я не агитирую за отмену делайнов, я агитирую за то, чтобы они были адекватными и чтобы к ошибкам в оценках дедлайнов относились адекватно.
Хехе, я как раз так и делаю. Считаю сроки по своим внутренним ощущениям, и потом домножаю на 2 или 3 :)
Очень хорошая мысль, которую я упустил из вида. Можно я ее добавлю в статью? (обязательно укажу, что это ваша заслуга)
Да, но я считаю, что линчевать программиста за неудачную оценку сроков неправильно. Он в своих лучших знаниях оценил трудоемкость и потом в своих лучших знаниях написал код. Наказыавть его не за что. Если есть подозрения, что он нечистоплотно оценивает сроки или нечистоплотно работает — вот тут уже можно заводить расследования и по результатам расследования наказывать.
Я бы скорее сказал, что если видно, что программист из раза в раз опаздывает по срокам, то я бы как менеджер, подошел бы к нему и поговорил бы на эту тему. Поинтересовался его мыслями, с чем это может быть связано и помог бы ему в будущем более правильно оценивать сроки.
3. Пару раз попав на собственных оптимистичных оценках программист к сожалению не начинает лучше оценивать и лучше работать — он начинает умножать свое первое представление на два, на три, на десять.
Хехе, я как раз так и делаю. Считаю сроки по своим внутренним ощущениям, и потом домножаю на 2 или 3 :)
4. Менеджер должен не просто стрясти оценку с разработчика, но и потребовать обоснования срока, тем самым проконтролировав что оценка взята не с потолка. Разработчика же такой подход заставит подойти к оценке более ответственно.
Очень хорошая мысль, которую я упустил из вида. Можно я ее добавлю в статью? (обязательно укажу, что это ваша заслуга)
7. Если назвал срок — пожалуйста за него отвечай, иначе это детский сад. Не можешь назвать — так и скажи, слишком велика неопределенность, или назови вилку, или оценку сверху. На угрозы и давление — pocker face.
Да, но я считаю, что линчевать программиста за неудачную оценку сроков неправильно. Он в своих лучших знаниях оценил трудоемкость и потом в своих лучших знаниях написал код. Наказыавть его не за что. Если есть подозрения, что он нечистоплотно оценивает сроки или нечистоплотно работает — вот тут уже можно заводить расследования и по результатам расследования наказывать.
Я бы скорее сказал, что если видно, что программист из раза в раз опаздывает по срокам, то я бы как менеджер, подошел бы к нему и поговорил бы на эту тему. Поинтересовался его мыслями, с чем это может быть связано и помог бы ему в будущем более правильно оценивать сроки.
Считаю сроки по своим внутренним ощущениям, и потом домножаю на 2 или 3 :)Попробуйте лучше декомпозировать задачу и прикинуть сроки отдельных этапов — это сильно повышает точность. Думаю вам может помочь моя давнишняя статья на близкую тему.
Да, но я считаю, что линчевать программиста за неудачную оценку сроков неправильно.Тут есть отличный проверенный подход: в случае факапа (даже если вас подвели другие люди или еще что-то) вы смело говорите — господа, это мой факап. Я во всем виноват. Бейте меня. И в этот момент ни в коем случае не добавляйте ссылки на чужую вину. Удивительно — но обычно в таких случаях менеджер успокаивается и проблема переходит в конструктивное русло. При разборе полетов уже можно упомянуть причины, разобрать все подробно. Главное вы уже сделали — показали себя ответственным специалистом, отвечающим за свое слово и набрали очков у руководства. Вас еще возьмут на карандаш, как кадровый резерв управления. Это конечно мой собственный опыт, где-то может и не сработать.
Очень хорошая мысль, которую я упустил из вида. Можно я ее добавлю в статью? (обязательно укажу, что это ваша заслуга)Конечно, без проблем.
Еще одна важная мысль пришла на ум:
10. Оценивая действия менеджера, нужно понимать, что он тоже отвечает за срок (который вы назвали) перед заказчиком или вышестоящим руководством. И на том уровне никто не примет от него отговорок, что виноват во всем программист. За факап его спросят по всей строгости.
Я ту статью уже прочитал :) Да, декомпозиция очень помогает с более адекватной оценкой трудоемкости. Такие сроки еще выступят в роли поверхностной проектировки и валидации (что все эти дикомпозитные части можно будет собрать в единое целое в конечном итоге). Просто я видать отношусь к этой группе безнадежных оптимистов — и я свою оптимистичность как раз и корректирую х2 или х3.
Я так и поступаю — есть есть какой-то факап, то виноват я, а не кто-то ниже по иерархии. Потому что так и есть. Если нафакапил я — то я и виноват. А если виноват кто-то ниже в иерархии, то виноват в том числе и я, т.к. я не проследил этот момент. Со стороны программиста правильно брать вину на себя и попросить прощения за то, что он не в писался в сроки. Но менеджер, мне кажется, не должен обвинять программиста в том, что программист не вписался в сроки. Менеджер скорее должен проанализировать ситуацию и помочь программисту в будущем не делать этой ошибки.
Я так и поступаю — есть есть какой-то факап, то виноват я, а не кто-то ниже по иерархии. Потому что так и есть. Если нафакапил я — то я и виноват. А если виноват кто-то ниже в иерархии, то виноват в том числе и я, т.к. я не проследил этот момент. Со стороны программиста правильно брать вину на себя и попросить прощения за то, что он не в писался в сроки. Но менеджер, мне кажется, не должен обвинять программиста в том, что программист не вписался в сроки. Менеджер скорее должен проанализировать ситуацию и помочь программисту в будущем не делать этой ошибки.
Со стороны программиста правильно брать вину на себя и попросить прощения за то, что он не в писался в сроки.Не надо прощения просить, это же не исповедь :) Просто признать свой косяк.
Но менеджер, мне кажется, не должен обвинять программиста в том, что программист не вписался в сроки. Менеджер скорее должен проанализировать ситуацию и помочь программисту в будущем не делать этой ошибки.Согласен абсолютно. Но менеджер должен быть уверен, что программист свою часть косяка осознает. Просто слишком часто попадаются люди, у которых виноваты все кругом и все что угодно, кроме них самих. С ними очень тяжело работать.
А какая разница кто виноват? Меня всегда удивляли проектные разборки, когда собиралась куча народу — менеджеры, продавцы, разработчики, начальники и обсуждали кто виноват. Чувство вины хоть кому-то помогало сделать проект?
Нужно понять ошибки, ни в коем случае не вынося на общее обсуждение, а думать нужно как ситуацию исправить. Порицание провинившихся ситуацию не исправляет.
Нужно понять ошибки, ни в коем случае не вынося на общее обсуждение, а думать нужно как ситуацию исправить. Порицание провинившихся ситуацию не исправляет.
Чувство вины хоть кому-то помогало сделать проект?Ни разу :)
Публичные разборки не нужны, вы абсолютно правы. Но если уж они состоялись — нужно уметь себя правильно вести.
А что нужно — вы сами ответили:
Нужно понять ошибки
И здесь задача менеджера проследить, чтобы все видели свои ошибки. Не просто чувствовали вину (это контрпродуктивно) а понимали — вот тут и тут нужно было сделать так и так. Чтобы не наступить на грабли повторно, в следующем проекте.
И здесь задача менеджера проследить, чтобы все видели свои ошибки.
То есть вызвать чувство вины…
Это не работает. Следующий раз человек будет думать не о том, как не совершить ошибку, а о том как избежать наказания (даже такого незначительного, как чувство вины).
Когда вас в школе родители ругали за плохие оценки — появлялось желание учиться лучше, а не идти в футбол гонять?
То есть вызвать чувство вины…Вы дочитали мой комментарий до конца?
Еще раз: никому не нужно ваше чувство вины, нужно ваше рациональное осознание собственных ошибок и ваше понимание как не допустить их снова.
Вы говорите про цель, а я говорю про результат. Это очень большой педагогический талант нужно иметь, чтобы донести до человека его ошибки, не вызвав чувство вины. Увы, большая часть такими талантами не обладает.
Да, согласен, бывает такое, сам наблюдал. Чаще с девушками.
Нужно повышать самооценку сотрудникам. И четко разделять работу и личные качества человека — не переходить в критике на личности.
Развитие самооценки — трудная психологическая работа, и если руководитель не имеет возможности ею заниматься — нужно еще при приеме на работу выяснять реакцию человека к критике.
Помню проводил собеседование с девушкой из МГУ. Все нормально было, дал тестовое задание на дом, как всем. Сделала быстро, но как говорится «на отвали». Я честно и подробно расписал все ошибки и дал рекомендации. При этом специально следил за языком, чтобы ни в коем случае не перейти на личности.
В ответ получил такое ведро помоев на себя и компанию, что даже отвечать не стал. Ну как с такими работать?
Нужно повышать самооценку сотрудникам. И четко разделять работу и личные качества человека — не переходить в критике на личности.
Развитие самооценки — трудная психологическая работа, и если руководитель не имеет возможности ею заниматься — нужно еще при приеме на работу выяснять реакцию человека к критике.
Помню проводил собеседование с девушкой из МГУ. Все нормально было, дал тестовое задание на дом, как всем. Сделала быстро, но как говорится «на отвали». Я честно и подробно расписал все ошибки и дал рекомендации. При этом специально следил за языком, чтобы ни в коем случае не перейти на личности.
В ответ получил такое ведро помоев на себя и компанию, что даже отвечать не стал. Ну как с такими работать?
Открою тайну — любую критику результатов своей деятельности человек воспринимает как личную. Даже если недостатки от самого человека не зависели. Поэтому прямо критиковать можно только с двух позиций — с позиции друга, когда однозначно критика не отразится на отношениях, и с позиции авторитета — если ты настолько крут, что все тебе кланяются.
И для любого менеджера по отношению к подчиненным эти позиции не существуют.
И для любого менеджера по отношению к подчиненным эти позиции не существуют.
Открою тайну — любую критику результатов своей деятельности человек воспринимает как личнуюНо ведь человек — не животное. Он может отрефлексировать (понять, оценить, изменить) собственную реакцию, не так ли?
И для любого менеджера по отношению к подчиненным эти позиции не существуютне соглашусь. расскажу свой опыт. Когда речь о рабочих вопросах — маска начальника. Никаких хи-хи, ха-ха и расслабона. Но когда мы шли вместе обедать, или в боулинг в пятницу — мы просто не говорили про работу. Обсуждали все что угодно, просто на равных.
Да, это лицемерие, но это работает.
Я немного встряну. Мне кажется, это правильно, что начальник должен стараться показать сотруднику его ошибку (иначе он будет продолжать ее совершать в будущем). Также он должен стараться не выходить за рабочие рамки (вот ошибка, вот почему она случилась, давай постараемся в будущем делать это и то-то, чтобы больше ее не было).
Это очень трудно, критиковать не вызывая негативную реакцию, но это возможно :) У меня на практике было, показал ошибку одному программисту — а он мне в тоне «хихи-хаха, точно, вот это я маху дал, исправлю и в будущем не буду больше так делать» ответил. Я явно ожидал немного больше драммы с его стороны. Было приятно осознать, что у меня получилось пройти этот путь развития отношений между нами, и мои упреки перестали быть личными для него. Мне кажется хороший руководитель должен уметь строить такие отношения со своими подчиненными, иначе руководитель не будет иметь возможности вести конструктивную критику. А без критике (без фидбека) никто не будет развиваться.
Это очень трудно, критиковать не вызывая негативную реакцию, но это возможно :) У меня на практике было, показал ошибку одному программисту — а он мне в тоне «хихи-хаха, точно, вот это я маху дал, исправлю и в будущем не буду больше так делать» ответил. Я явно ожидал немного больше драммы с его стороны. Было приятно осознать, что у меня получилось пройти этот путь развития отношений между нами, и мои упреки перестали быть личными для него. Мне кажется хороший руководитель должен уметь строить такие отношения со своими подчиненными, иначе руководитель не будет иметь возможности вести конструктивную критику. А без критике (без фидбека) никто не будет развиваться.
Когда вас в школе родители ругали за плохие оценки — появлялось желание учиться лучше, а не идти в футбол гонять?У кого как. И смотря как ругали…
Если разраб заранее не знает как решить задачу то а) за него это могут сделать более скиловые разрабы б) разраб может попросить время на ресерч.
Есть подозрение, что даже более скиловые разрабы не знают решения в большинстве случаев. Они представляет в каком направлении двигаться, какие примерно проблемы могут возникнуть, но точное решение еще не известно. И время на ресерч = времени на разработку+время на написания отчета.
Но почему-то действительно скиловые разработчики довольно точно попадают в свои оценки сроков.
И время на ресерч = времени на разработку+время на написания отчета.Это как? поясните.
Но даже у скиловых разработчиков бытуют оценка по принципу — все аккуратно посчитать, потом сразу умножить на 2.
Все тонкости и проблемы разработки ( которые требуется оценить) обычно всплывают только при разработке и оценить потраченное на них время можно только с ними столкнувшись. Опытные разрабы могут предугадать большую часть проблем, но даже они могут наткнуться на неприятности. Поэтому гарантированно оценить время на разработку можно только непосредственно разработкой.
Все тонкости и проблемы разработки ( которые требуется оценить) обычно всплывают только при разработке и оценить потраченное на них время можно только с ними столкнувшись. Опытные разрабы могут предугадать большую часть проблем, но даже они могут наткнуться на неприятности. Поэтому гарантированно оценить время на разработку можно только непосредственно разработкой.
Согласен. Никому и не нужна точность день-в-день. Нужно всего лишь получить оценку сверху, на которую согласны обе стороны — Заказчик и Исполнитель.
Но оценка сверху может быть значительно превышена из-за всяких неожиданностей. Закладывай хоть 200% запас, все равно в каком-то проценте случаев она будет превышена.
Это риски, конечно они есть. И ими тоже можно управлять.
Тут дело не в рисках, а в постановке задачи. Зачастую все процессы выстроены так, что накапливаются только отставания, а вот сэкономленное на задачах время никак не сохраняется. На то может быть множество причин, но все они сводятся к одной корневой проблеме — неэффективный подход к управлению проектами. Довольно часто бывает, что никакие риски по факту не сработали, а дедлайны все-равно выдерживаются ценой бесчеловечных авралов в последнюю неделю. И иногда даже нельзя точно сказать почему так вышло, просто так получилось.
дедлайны все-равно выдерживаются ценой бесчеловечных авралов в последнюю неделюС этим сталкивался постоянно, а вот
И иногда даже нельзя точно сказать почему так вышло, просто так получилось.с таким — никогда.
95% процентов провалов сроков так или иначе были связаны с одной или нескольких тривиальных причин (в порядке популярности):
1. Неточная или некорректная постановка задачи. Отсутствие управления требованиями.
2. Отсутствие промежуточных точек контроля, только по результату.
3. Неправильная оценка трудоемкости (как правило из-за п.1)
4. Отсутствие управления качеством. (Сделали быстро — но налепили столько ошибок, что не успели все исправить)
Вот с этим я поспорю. Что значит подойти к оценке более ответственно?Поверхностная декомпозиция с оценкой этапов, хотя бы.
Самый лучший вариант решения — не спрашивать срок вообще. Проводить оценку трудоемкости в единицах, не привязанных ко времени. В условных попугаях например. Взять проект, порезать на фичи, оценить фичи, желательно по неравномерной шкале (Фибоначчи например).
А потом взять уже выполненый проект, схожий с новым, порезать на фичи, оценить в тех же самых попугаях. Потом реальные вычислить продуктивность (попугаев в единицу времени) на основе реального срока реального проекта. И умножить на оценку первого, вот и срок получится. Причем этот срок уже будет содержать риски их не надо будет дополнительно оценивать.
Далее расчетный срок делится на Пи и уже в полученный временной отрезок напихиваются задачи. Таким образом исключаем синдром студента (сделать все в ночь перед сдачей), исключаем чувство вины разработчиков (не они назначали сроки, а менеджмент), имеем адекватный буфер на работы (не раздутый, а отражающий реальность), поэтому непопадание в заданный временной не будет вызывать негатива, который потом будет спускаться на программистов.
Проблема только тогда, когда и проект новый, и команда новая и менеджер новый. В этих случаях сроки можно только угадать и тут лучше перезаложиться (читай умножить на Пи_в_квадрате), чем просто просуммировать все оценки программистов, а потом прессовать в случае непопадания.
А потом взять уже выполненый проект, схожий с новым, порезать на фичи, оценить в тех же самых попугаях. Потом реальные вычислить продуктивность (попугаев в единицу времени) на основе реального срока реального проекта. И умножить на оценку первого, вот и срок получится. Причем этот срок уже будет содержать риски их не надо будет дополнительно оценивать.
Далее расчетный срок делится на Пи и уже в полученный временной отрезок напихиваются задачи. Таким образом исключаем синдром студента (сделать все в ночь перед сдачей), исключаем чувство вины разработчиков (не они назначали сроки, а менеджмент), имеем адекватный буфер на работы (не раздутый, а отражающий реальность), поэтому непопадание в заданный временной не будет вызывать негатива, который потом будет спускаться на программистов.
Проблема только тогда, когда и проект новый, и команда новая и менеджер новый. В этих случаях сроки можно только угадать и тут лучше перезаложиться (читай умножить на Пи_в_квадрате), чем просто просуммировать все оценки программистов, а потом прессовать в случае непопадания.
Интересный подход. И как, работает? Понятно, что в сравнении с традиционным он даст кое-какой профит, но насколько значительный?
Я не язвлю, мне правда интересно посмотреть результаты. Я вижу, что опять есть традиционная перестраховка, которая должна дать необоснованно завышенные сроки, но это завышение вынесено в буфер, что хорошо. Вижу, что оценка делается позадачно, что в свою очередь ведет к повышению вероятности срабатывания скрытого риска, когда сами по себе задачи выполнены в срок или раньше, а про магический компонент, который вдохнет жизнь в приложение, все на этапе оценки забыли. Т.е. на мой взгляд ключевые ограничения традиционного подхода не устранены, но сам подход модифицирован. От того и вопрос, дала ли эта модификация ощутимый эффект?
Я не язвлю, мне правда интересно посмотреть результаты. Я вижу, что опять есть традиционная перестраховка, которая должна дать необоснованно завышенные сроки, но это завышение вынесено в буфер, что хорошо. Вижу, что оценка делается позадачно, что в свою очередь ведет к повышению вероятности срабатывания скрытого риска, когда сами по себе задачи выполнены в срок или раньше, а про магический компонент, который вдохнет жизнь в приложение, все на этапе оценки забыли. Т.е. на мой взгляд ключевые ограничения традиционного подхода не устранены, но сам подход модифицирован. От того и вопрос, дала ли эта модификация ощутимый эффект?
Метод в Agile широко используется. Оценка в попугаях (и Фибоначчи вполне отражает логику усложнения взаимосвязей в системе по мере увеличения сложности фичи), а потом конвертация попугаев в часы. Вопрос только в конвертации. Использование базы и последующие манипуляции — один из способов. Можно также использовать оценку одной задачи или эксперимент для определения временной стоимости одного попугая.
На мой взгляд, это те же часы трудозатрат, только в профиль. Точности попугаи не прибавляют, но как элемент риск-менеджмента они годные, при подобранном по ситуации способе конвертации. Макконнел писал что «если можете сделать оценку посчитав — лучше посчитайте».
Что же касается буферов, то критическая цепь это вообще отдельный разговор. Лично мне кажется её слабым звеном как раз опора на существование «синдрома студента». Если как-то переработать творчески эту часть метода, то сама концепция буферов несомненно полезная.
Потеря магических задач — это не проблема позадачного метода. Это проблема проектирования и трансляции дизайна системы в задачи. Мой опыт противится оценке проектов «сверху», по проекту в целом: это можно делать при анализе выгод, но для управления это не подходит (а оценка снизу-вверх годится для всего). Проект вобщем-то не черный ящик, и любая информация о его устройстве позволяет его оптимизировать. Если бы сам не проделывал неоднократно путем «переставления колбасок» чудеса с укорочением проектов, может и не верил бы в это. Но так — знаю.
На мой взгляд, это те же часы трудозатрат, только в профиль. Точности попугаи не прибавляют, но как элемент риск-менеджмента они годные, при подобранном по ситуации способе конвертации. Макконнел писал что «если можете сделать оценку посчитав — лучше посчитайте».
Что же касается буферов, то критическая цепь это вообще отдельный разговор. Лично мне кажется её слабым звеном как раз опора на существование «синдрома студента». Если как-то переработать творчески эту часть метода, то сама концепция буферов несомненно полезная.
Вижу, что оценка делается позадачно, что в свою очередь ведет к повышению вероятности срабатывания скрытого риска, когда сами по себе задачи выполнены в срок или раньше, а про магический компонент, который вдохнет жизнь в приложение, все на этапе оценки забыли.
Потеря магических задач — это не проблема позадачного метода. Это проблема проектирования и трансляции дизайна системы в задачи. Мой опыт противится оценке проектов «сверху», по проекту в целом: это можно делать при анализе выгод, но для управления это не подходит (а оценка снизу-вверх годится для всего). Проект вобщем-то не черный ящик, и любая информация о его устройстве позволяет его оптимизировать. Если бы сам не проделывал неоднократно путем «переставления колбасок» чудеса с укорочением проектов, может и не верил бы в это. Но так — знаю.
Я описал классический скрам и методику прикидывания velocity до старта проекта. И то и другое у меня работало. Сравнивать толком не с чем, ибо с той же командой я не по скраму не работал. Но по субъективным ощущениями скрам в разы лучше.
Оценок сроков задач нет. Вернее они есть, но на контрольные точки не влияют. Поэтому и предлагаю все задачи по одной фиче изначально утрамбовать в треть от расчетного срока, чтобы всяческая неучтенка не подвинула сроки релизов.
Кроме того надо понимать, что полученное значение velocity — среднее, а в реальности velocity может сильно варьироваться в ходе проекта, снижаясь к концу проекта. Поэтому в ходе проекта надо не стремиться попасть в расчетное значение, а увеличивать velocity. Это надо доносить и до команды.
Оценок сроков задач нет. Вернее они есть, но на контрольные точки не влияют. Поэтому и предлагаю все задачи по одной фиче изначально утрамбовать в треть от расчетного срока, чтобы всяческая неучтенка не подвинула сроки релизов.
Кроме того надо понимать, что полученное значение velocity — среднее, а в реальности velocity может сильно варьироваться в ходе проекта, снижаясь к концу проекта. Поэтому в ходе проекта надо не стремиться попасть в расчетное значение, а увеличивать velocity. Это надо доносить и до команды.
Серебряных пуль не бывает, везде надо искать золотую середину, если коротко:)
работники должны понимать, что им лучше «провалить» дедлайн, если в противном случае они бы написали костыли или если в противном случае они бы исчерпали себя эмоционально.
Не согласен. Для всего есть время и место. Надо помнить, что цель работы — это создание продукта, а не игра с кодом. Выпущенный продукт (фича, что угодно) с костылями или идеальный продукт, но «когда-нибудь потом»?
Я не имел ввиду тихо скромно сливать сроки, а имел ввиду, что подойти к начальству и обсудить вопрос того, что они не успевают — это нормально. Возможно, начальству важнее лишь бы качесчтенно было или лишь бы программисты не выгорали. Часто программисты, воспринимая сроки как карательный инструмент, фигачат по ним даже не пытаясь вынести вопрос о переносе сроков на обсуждение. То есть я предлагаю, что на всех уровнях к срокам должны относиться, как к оценке, а не точной дате. Когда-то выпустить нужно в срок и хоть кровь из носу, а иногда сроки можно подвинуть. Таким образом сроки не будут каким-то объектом (иногда дешевых) торгов между программистами-менеджером-заказчиком, а будут в рабочем порядке обсужадться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Польза и вред от сроков (deadlines) в программировании