Комментарии 4
Проблема в том, что разработчики дают противоположные по смыслу обещания, которые они не способны выполнить одновременно:
1. «ПО может быть получено, путем композиции простых операций, которые мы умеем делать» → «дорогой менеджер, не мог бы ты, пожалуйста, составить план разработки ПО из этих операций, а мы его реализуем максимально хорошо».
2. «У нас есть и свои потребности, которые мы могли бы удовлетворить с помощью ПО» → «дорогой менеджер, пожалуйста, позволь нам самим организовывать свое время и результат, возможно, даже превысит твои ожидания».
Разумеется, одновременно эти обещания не могут быть выполнены и причина этому — реальная жизнь:
1. Первое обещание не может быть выполнено, потому что сегодня мы в большей степени аутсорсим наши усилия: мы составляем ПО из готовых чужих модулей, ПО крутится на не контролируемом нами окружении (в облаке) и нас самих учат программированию другие люди, мы не постигаем его с нуля.
2. Увы, постижение мастерства реализации конкретного ПО с нуля и до последнего байта методом проб и ошибок просто слишком долго. Рыночное окно для этого ПО просто закроется, когда мы изучим все необходимое.
Совместить оба подхода можно с помощью прозрачности: менеджер держит в голове полную картину, но вы ему честно говорите какой ваш личный интерес в решении этой задачи.
Поскольку мириться с несовершенством жизни менеджер умеет и так, остается только научить его мириться с вами.
Т.е. идеальный эстимейт: «эта задача займет 2 часа, но я еще хочу дописать документацию и причесать код, поэтому 4 часа».
Менеджер может не согласиться, поскольку проект требуется реализовать в сжатые сроки, или по другим причинам. Ну штош.
1. «ПО может быть получено, путем композиции простых операций, которые мы умеем делать» → «дорогой менеджер, не мог бы ты, пожалуйста, составить план разработки ПО из этих операций, а мы его реализуем максимально хорошо».
2. «У нас есть и свои потребности, которые мы могли бы удовлетворить с помощью ПО» → «дорогой менеджер, пожалуйста, позволь нам самим организовывать свое время и результат, возможно, даже превысит твои ожидания».
Разумеется, одновременно эти обещания не могут быть выполнены и причина этому — реальная жизнь:
1. Первое обещание не может быть выполнено, потому что сегодня мы в большей степени аутсорсим наши усилия: мы составляем ПО из готовых чужих модулей, ПО крутится на не контролируемом нами окружении (в облаке) и нас самих учат программированию другие люди, мы не постигаем его с нуля.
2. Увы, постижение мастерства реализации конкретного ПО с нуля и до последнего байта методом проб и ошибок просто слишком долго. Рыночное окно для этого ПО просто закроется, когда мы изучим все необходимое.
Совместить оба подхода можно с помощью прозрачности: менеджер держит в голове полную картину, но вы ему честно говорите какой ваш личный интерес в решении этой задачи.
Поскольку мириться с несовершенством жизни менеджер умеет и так, остается только научить его мириться с вами.
Т.е. идеальный эстимейт: «эта задача займет 2 часа, но я еще хочу дописать документацию и причесать код, поэтому 4 часа».
Менеджер может не согласиться, поскольку проект требуется реализовать в сжатые сроки, или по другим причинам. Ну штош.
Менеджеров интересует полная оценка сроков выполнения с учетом зависимостей, исполнитель сроков зависимостей оценить объективно не может. Плохие менеджеры слепо закладывают запасы или используют PERT, ошибаются в разы и винят исполнителей. Хорошие менеджеры, знают что точность PERT лишь 66% и объясняют заказчику AGILE ценности, прежде всего пользу скорейшего и регулярного релиза продукта с учетом fix time & budget, flex scope.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Об эстимейтах-2