Чутка анализа статьи, какая-то она не однозначная.
Вот в целом какая цель у оценки? С точки зрения управленца, и это говорится во многих книгах, необходимо понимать когда, примерно, будет выпущена та или иная фича. Для чего? Очевидно, что есть процессы помимо разработки и тестирования и было бы круто выполнять их параллельно. Для этого надо понимать когда будет выполнена та или иная часть работы. Нередко бывает что руководитель говорит — “Надо через три дня, успеешь?”. Тут да, менеджер из него так себе (правда иногда такое бывает и с хорошими менеджерами). В такой ситуации, конечно, появляется чувство, что тебя прижали к стенке.
“Я считаю абсолютно вредной практику, когда исполнитель оценивает сроки на выполнение отдельной задачи.”
Во-первых, получается, что он считает оценку фичи полезной, раз не сказано обратного. Речь только о задачах, как я понял. Это же следует и из названия статьи. Во-вторых, он считает вредной практику оценки задач исполнителем, получается оценка задач менеджером, тимлидом, коллегой с другого проекта или командой уже не вредная, как минимум. А вот если доколупаться до Васи с вопросом сколько он потратит на задачу к которой приступает, это да, это вредно. Можно возразить, что это мои придирки, но все остальное будет просто мнением, основанным на ваших мыслях, которые могут не соответствовать мыслям автора.
“Это напрямую связано с отсутствием системного образования и низкими требованиями к менеджерам.”
Так, погодите, отсутствие системного образования у кого, у менеджера или того, кто будет оценивать? Это важно. Отсутствие системного образования (при чем здесь это вообще?) у менеджера может привести к ожиданию, что задача будет выполнена через Х часов с момента начала работы над ней. А у исполнителя, может создастся ощущение, что есть некий дедлайн и выход за его рамки приведет к ухудшению мнения о нем как о разработчике/тестировщике. Здесь важнее общее понимание оценки обеими сторонами и того, что может произойти при нарушении договоренности. Вторая часть предложения про низкие требования к менеджерам — это вообще о чем? Не, ну правда, не нравится менеджер и его методы, поговори с ним, объясни, что не так. Менеджеры не телепаты, им тоже нужна обратная связь, если он адекватный человек, то будет благодарен за фидбэк. Если не зашло, иди к директору, проси сменить менеджера, в чем проблема?
“К нам приходит человек, ставит задачу и спрашивает, сколько времени может занять ее выполнение. Оценивая задачу, мы, конечно же, хотим назвать тот срок, к которому точно успеем, а так как многое может случиться (и мы подозреваем, что что-то наверняка случится), мы закладываем в оценку некий запас времени.
В итоге любой названный в качестве дедлайна срок становится сроком, раньше которого задача выполнена не будет. К особо неприятным последствиям это приводит при командной работе, когда для выполнения одной задачи или проекта требуется сотрудничество разных специалистов и разных отделов.”
Логично и правдиво, но! Заметили ли вы логическую ошибку? По отдельности я согласен с каждым этим абзацем, а вот вместе нет. В одном речь про оценку, а во втором про срок! Это же разные понятия… Это к вопросу про системность образования. Абзацы вырваны из контекста и совмещены. Будь я чуточку менее внимателен, то проглотил бы это. Это же Макс Дорофеев написал! КЛАССИК! Интересно знает ли он сам про это? Оценка, это “За час, в течении недели”, а срок “Будет через час”.
“В пятой части первой главы есть ссылки на исследования о зависимости производительности от того, кто выполнял оценку сроков.”
Ну давайте почитаем эту часть вместе и добавим цитаты с небольшими комментариями:
“В 1954 году англичанин Сирил Паркинсон выразил мнение, что работа растѐт, заполняя любое отведѐнное под неѐ время. Сейчас это мнение известно как закон Паркинсона”
“Даже руководители, не знающие вообще ничего о менеджменте, цепляются за эту аксиоматическую истину – закон Паркинсона, руководящую людьми и их отношением к работе. Он даѐт им крайнюю убеждѐнность в том, что единственный способ добиться выполнения работы – это установить невозможно оптимистические сроки еѐ сдачи.”
Смотрите ка, опять про сроки, а не про оценку…
Книга, судя по пятой части первой главы, интересная. Что я вынес из прочтения этого отрывка. Во-первых, исследование на которое ссылается автор книги датирована 1985 годом. Скрам и аджаил в целом, а именно они возникают у меня в голове при слове “оценка”, был сформирован в 2000-ых. И подход к оценке был изменен. Можно почитать “Мифический человеко-месяц” (1975), что-то мне подсказывает, что есть на эту тему информация. Оценка в скраме несет приблизительный характер (попугайчики), а размер спринта зависит от среднего объема выполняемого командой за некоторое количество предыдущих спринтов. Кроме того, оценка производится коллективно, а не непосредственно исполнителем.
Продолжим разбор статьи.
“За последний год я дважды слышал от менеджеров: «Мы научились выдерживать сроки по оценкам задач, теперь такой-то программист или тестировщик совсем не нарушает сроки, которые назвал».
Я считаю, это крайне серьезная проблема, так как это означает, что этот программист или тестировщик системно и сознательно завышает сроки, работает на расслабоне и лжет менеджеру.”
И что? Менеджер доволен, у него не срываются другие процессы из-за разработки/тестирования. Программист/тестировщик тоже, у него нет чувства горящей пятой точки. А если возникает ощущение, что оценка завышена, то можно делать это коллективно и брать среднее значение оценки. Ничего нового, просто немного понимания скрама. Если какой-то сотрудник сильно отстает по производительности, то это повод к выяснению причин.
“Упомянутые в заголовке авторы говорят, что единственно верный способ оценки сроков — статистический. Должен оцениваться пакет типовых задач. «У нас все задачи разные»? Это ложь. На промежутке в год будет уже не очень много разных задач. Как правило, такое заявление является признаком отсутствия рефлексии над процессом и не выполнения упражнений: декомпозиция, MVP, прототипы, стандартизация.”
Бррр, да это же опровергает все что было написано автором до этого, нет? Лично у меня этот абзац не вызывает чувства отрицания сам по себе, но автору-то он зачем?
“О заказчиках, которые требуют сроки
Во-первых, надо заметить, что чаще всего — и это само по себе забавно — от ответа исполнителя не зависит ничего, потому что сроки уже есть. Менеджер интересуется не сколько времени мы будем делать задачу, а успеем ли мы к заданному сроку и что именно успеем. Это разные вопросы и отвечать на них нужно по-разному.
Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.”
Как? Как из этих двух абзацев следует вывод — “Ещё раз: оценка сроков мешает исполнителю успеть к дедлайну.” Я могу что-то с этим придумать, конечно, сделать какие-то домыслы, но это не то, что я ожидал от статьи.
Далее приводится список упражнений (среди которых MVP), которые рекомендуются к выполнению для повышения точности сроков и вывод:
“Если упражнения не выполняются, то скорее всего любой названный менеджером срок будет ложью.”
Ну как так-то? Вот представим ситуацию. Приходит заказчик и приносит требования, просит оценить сроки выполнения и бюджет. А мы ему такие: “Так, товарищ, надо запилить MVP и выпустить его канареечными релизами! Если вам нужна более точная оценка оценка, то в этом нам поможет раздельный релиз бэкэнда, фронтенда и прочего… и канарейки. И не забудьте про фича-флаги!”. И как нам это поможет?
“О некомпетентных менеджерах
Очень легко перепутать оценку сроков (когда задача будет сделана) и оценку трудозатрат (сколько нужно времени, чтобы разработать фичу). Оценка сроков, как мы уже разобрались, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение.”
Зачем? Ну что кому даст оценка трудозатрат сама по себе? Разумеется она нужна, но, только в контексте оценки сроков. И эти две оценки очень тесно связаны. Просто надо добавить еще один параметр — количество выполняемого труда командой проекта. И тогда все встает на свои места. Оценили трудозатраты, знаем производительность команды, следовательно, можем получить оценку сроков. Если что-то меняется в требованиях, то происходит изменение оценки.
“Пример из жизни:
— Сколько времени ты потратишь на эту фичу?
— Полторы недели буду писать и дня три фиксить баги.
— То есть через 3-4 недели будет готово?”
А где продолжение? Ну ответил — “да” и сделал, у него же не лапки. Или ответил — “У меня сейчас большая загруженность. Давай посмотрим бэклог и подумаем над приоритетом этой фичи (посмотрели — вставили в бэклог — сделали)”. Где интрига-то?
“P.S. Один из наиболее важных навыков в нашей работе — не делать ненужной херни. В том числе не заниматься «оценкой сроков» и самообманом. Чего и вам желаю.”
Про самообман хорошо сказал…
Вот в целом какая цель у оценки? С точки зрения управленца, и это говорится во многих книгах, необходимо понимать когда, примерно, будет выпущена та или иная фича. Для чего? Очевидно, что есть процессы помимо разработки и тестирования и было бы круто выполнять их параллельно. Для этого надо понимать когда будет выполнена та или иная часть работы. Нередко бывает что руководитель говорит — “Надо через три дня, успеешь?”. Тут да, менеджер из него так себе (правда иногда такое бывает и с хорошими менеджерами). В такой ситуации, конечно, появляется чувство, что тебя прижали к стенке.
“Я считаю абсолютно вредной практику, когда исполнитель оценивает сроки на выполнение отдельной задачи.”
Во-первых, получается, что он считает оценку фичи полезной, раз не сказано обратного. Речь только о задачах, как я понял. Это же следует и из названия статьи. Во-вторых, он считает вредной практику оценки задач исполнителем, получается оценка задач менеджером, тимлидом, коллегой с другого проекта или командой уже не вредная, как минимум. А вот если доколупаться до Васи с вопросом сколько он потратит на задачу к которой приступает, это да, это вредно. Можно возразить, что это мои придирки, но все остальное будет просто мнением, основанным на ваших мыслях, которые могут не соответствовать мыслям автора.
“Это напрямую связано с отсутствием системного образования и низкими требованиями к менеджерам.”
Так, погодите, отсутствие системного образования у кого, у менеджера или того, кто будет оценивать? Это важно. Отсутствие системного образования (при чем здесь это вообще?) у менеджера может привести к ожиданию, что задача будет выполнена через Х часов с момента начала работы над ней. А у исполнителя, может создастся ощущение, что есть некий дедлайн и выход за его рамки приведет к ухудшению мнения о нем как о разработчике/тестировщике. Здесь важнее общее понимание оценки обеими сторонами и того, что может произойти при нарушении договоренности. Вторая часть предложения про низкие требования к менеджерам — это вообще о чем? Не, ну правда, не нравится менеджер и его методы, поговори с ним, объясни, что не так. Менеджеры не телепаты, им тоже нужна обратная связь, если он адекватный человек, то будет благодарен за фидбэк. Если не зашло, иди к директору, проси сменить менеджера, в чем проблема?
“К нам приходит человек, ставит задачу и спрашивает, сколько времени может занять ее выполнение. Оценивая задачу, мы, конечно же, хотим назвать тот срок, к которому точно успеем, а так как многое может случиться (и мы подозреваем, что что-то наверняка случится), мы закладываем в оценку некий запас времени.
В итоге любой названный в качестве дедлайна срок становится сроком, раньше которого задача выполнена не будет. К особо неприятным последствиям это приводит при командной работе, когда для выполнения одной задачи или проекта требуется сотрудничество разных специалистов и разных отделов.”
Логично и правдиво, но! Заметили ли вы логическую ошибку? По отдельности я согласен с каждым этим абзацем, а вот вместе нет. В одном речь про оценку, а во втором про срок! Это же разные понятия… Это к вопросу про системность образования. Абзацы вырваны из контекста и совмещены. Будь я чуточку менее внимателен, то проглотил бы это. Это же Макс Дорофеев написал! КЛАССИК! Интересно знает ли он сам про это? Оценка, это “За час, в течении недели”, а срок “Будет через час”.
“В пятой части первой главы есть ссылки на исследования о зависимости производительности от того, кто выполнял оценку сроков.”
Ну давайте почитаем эту часть вместе и добавим цитаты с небольшими комментариями:
“В 1954 году англичанин Сирил Паркинсон выразил мнение, что работа растѐт, заполняя любое отведѐнное под неѐ время. Сейчас это мнение известно как закон Паркинсона”
“Даже руководители, не знающие вообще ничего о менеджменте, цепляются за эту аксиоматическую истину – закон Паркинсона, руководящую людьми и их отношением к работе. Он даѐт им крайнюю убеждѐнность в том, что единственный способ добиться выполнения работы – это установить невозможно оптимистические сроки еѐ сдачи.”
Смотрите ка, опять про сроки, а не про оценку…
Книга, судя по пятой части первой главы, интересная. Что я вынес из прочтения этого отрывка. Во-первых, исследование на которое ссылается автор книги датирована 1985 годом. Скрам и аджаил в целом, а именно они возникают у меня в голове при слове “оценка”, был сформирован в 2000-ых. И подход к оценке был изменен. Можно почитать “Мифический человеко-месяц” (1975), что-то мне подсказывает, что есть на эту тему информация. Оценка в скраме несет приблизительный характер (попугайчики), а размер спринта зависит от среднего объема выполняемого командой за некоторое количество предыдущих спринтов. Кроме того, оценка производится коллективно, а не непосредственно исполнителем.
Продолжим разбор статьи.
“За последний год я дважды слышал от менеджеров: «Мы научились выдерживать сроки по оценкам задач, теперь такой-то программист или тестировщик совсем не нарушает сроки, которые назвал».
Я считаю, это крайне серьезная проблема, так как это означает, что этот программист или тестировщик системно и сознательно завышает сроки, работает на расслабоне и лжет менеджеру.”
И что? Менеджер доволен, у него не срываются другие процессы из-за разработки/тестирования. Программист/тестировщик тоже, у него нет чувства горящей пятой точки. А если возникает ощущение, что оценка завышена, то можно делать это коллективно и брать среднее значение оценки. Ничего нового, просто немного понимания скрама. Если какой-то сотрудник сильно отстает по производительности, то это повод к выяснению причин.
“Упомянутые в заголовке авторы говорят, что единственно верный способ оценки сроков — статистический. Должен оцениваться пакет типовых задач. «У нас все задачи разные»? Это ложь. На промежутке в год будет уже не очень много разных задач. Как правило, такое заявление является признаком отсутствия рефлексии над процессом и не выполнения упражнений: декомпозиция, MVP, прототипы, стандартизация.”
Бррр, да это же опровергает все что было написано автором до этого, нет? Лично у меня этот абзац не вызывает чувства отрицания сам по себе, но автору-то он зачем?
“О заказчиках, которые требуют сроки
Во-первых, надо заметить, что чаще всего — и это само по себе забавно — от ответа исполнителя не зависит ничего, потому что сроки уже есть. Менеджер интересуется не сколько времени мы будем делать задачу, а успеем ли мы к заданному сроку и что именно успеем. Это разные вопросы и отвечать на них нужно по-разному.
Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.”
Как? Как из этих двух абзацев следует вывод — “Ещё раз: оценка сроков мешает исполнителю успеть к дедлайну.” Я могу что-то с этим придумать, конечно, сделать какие-то домыслы, но это не то, что я ожидал от статьи.
Далее приводится список упражнений (среди которых MVP), которые рекомендуются к выполнению для повышения точности сроков и вывод:
“Если упражнения не выполняются, то скорее всего любой названный менеджером срок будет ложью.”
Ну как так-то? Вот представим ситуацию. Приходит заказчик и приносит требования, просит оценить сроки выполнения и бюджет. А мы ему такие: “Так, товарищ, надо запилить MVP и выпустить его канареечными релизами! Если вам нужна более точная оценка оценка, то в этом нам поможет раздельный релиз бэкэнда, фронтенда и прочего… и канарейки. И не забудьте про фича-флаги!”. И как нам это поможет?
“О некомпетентных менеджерах
Очень легко перепутать оценку сроков (когда задача будет сделана) и оценку трудозатрат (сколько нужно времени, чтобы разработать фичу). Оценка сроков, как мы уже разобрались, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение.”
Зачем? Ну что кому даст оценка трудозатрат сама по себе? Разумеется она нужна, но, только в контексте оценки сроков. И эти две оценки очень тесно связаны. Просто надо добавить еще один параметр — количество выполняемого труда командой проекта. И тогда все встает на свои места. Оценили трудозатраты, знаем производительность команды, следовательно, можем получить оценку сроков. Если что-то меняется в требованиях, то происходит изменение оценки.
“Пример из жизни:
— Сколько времени ты потратишь на эту фичу?
— Полторы недели буду писать и дня три фиксить баги.
— То есть через 3-4 недели будет готово?”
А где продолжение? Ну ответил — “да” и сделал, у него же не лапки. Или ответил — “У меня сейчас большая загруженность. Давай посмотрим бэклог и подумаем над приоритетом этой фичи (посмотрели — вставили в бэклог — сделали)”. Где интрига-то?
“P.S. Один из наиболее важных навыков в нашей работе — не делать ненужной херни. В том числе не заниматься «оценкой сроков» и самообманом. Чего и вам желаю.”
Про самообман хорошо сказал…