Главный вопрос, который нас интересует при постановке задачи - как быстро она будет сделана. Но не всегда мы этот вопрос задаём. А зря. Даже если заказчик не требует сроков, это значит лишь одно из двух:
Он считает, что всё будет сделано “ещё вчера”
Задачу ставит человек без опыта и дело закончится конфликтом
Подходы к оценке времени
Менеджеры и исполнители, ловившие “люли” за сорванные сроки, практикуют различные "инструменты управления", чтобы отвязаться от неприятного вопроса “Когда?”. Приведу примеры, с которыми сталкивался лично я (что уж греха таить, сам практиковал):
Уклонение
Лучший способ избежать последствий от сорванных сроков - не называть этих сроков: "Не могу сейчас сказать", "Не буду даже пытаться", "Скажу завтра - может, забудут уточнить?", "Это нетипичная задача", "У нас сейчас много задач"... Прокатывает, но не со всеми и не каждый раз.
Ложь
“Через пару часов будет готово”. Это бывает неумышленно (по неопытности), или умышленно (пофигизм обыкновенный), но регулярно. 90% сроков, которые я слышу - сорванные с облаков произвольные величины времени. И это грустно. Не надо врать - лучше уж уклоняйтесь…
Делегирование
А давайте не PM, а исполнитель скажет, сколько времени уйдёт на таск? А давайте! В случае срыва (гарантия 100%) делаем грустное лицо: - Ох уж этот верстальщик… Заболел… Не успел… О[}:{]ел… В общем, способ “делегирование” в чистом виде практически эквивалентен способу “ложь”.
Умножение
Не со всеми прокатывает делегирование? Что же, мотаем на ус и умножаем срок от исполнителя на два (три, четыре, пять - учимся считать). С другой стороны, это уже попахивает риск-менеджментом и другими умными словами. Правда, коэффициент приходится постоянно нормировать на конкретного исполнителя и заказчика. Как выхлоп - известное правило, что работа занимает все отведенное на неё время.
Абстракция
“На эту задачу уйдёт пять часов” - звучит здраво, опытно и обнадеживающе. Но проходит неделя и задача не выполнена. Как так? Мы же трудились без перерыва! Кофе, перекур, обсуждение тачки начальника - был завал, делали другие задачи, смотрели в окно. Какое-то время это прокатывает, даже очень неплохо. До тех пор, пока не входит в систему. В перспективе превращается в способ оценки “ложь”, причем, очевидный для обеих сторон.
Принятие оценки клиента
Нужно сделать за неделю? Принято! Не успели? - Так Вы сами же поставили еще 10 задач! Так у нас же крыша протекла! Чёрный кот дорогу перебежал с утра.
Степень неадекватности такого рода уклонения зависит лишь от лояльности зрителя (заказчика). Срок, спущенный сверху, НИКОГДА не является зоной ответственности исполнителя. Заказчик может лишь высказывать пожелания или назначать предельные точки исполнения, в рамках которых задача имеет смысл (и это необходимо делать), но оценка реальности исполнения должна прилетать от исполнителя.
А какие ты знаешь?
Делись в комментариях. Делать этого ты, конечно же, не будешь)
Реальные практики планирования сроков
Учитывая все приёмы “уклонистов”, в цепочке постановки сроков нужно лавировать между здравым смыслом и желанием достичь результата. Это значит, что ты обязан знать все возможные приемы в уклонении и извлекать из них профит:
Требовать
Получать сроки от исполнителя или другого ПМ по цепочке - это необходимость. Иначе получаем бесконечную задачу. Это просто реальность, в которой мы живём. Не получив срока, не получишь результат. И обязательным условием является наглядная фиксация. Исполнитель должен понимать дату, под которой подписался, и за которую с него спросят.
Уточнять
Так как практика учит: большинство сроков не соблюдаются, наивно надеяться, что в конкретном случае всё пойдёт не так. Перестраховывайся. Обновление актуального состояния прогресса и сроков по ходу выполнения задачи - не невроз или прихоть, а необходимость. Если процесс критичен, то время от времени уточняй, насколько актуальна первичная оценка времени и сколько потребуется ещё ресурсов для завершения теперь.
Не назначать самому
Разве что можно обозначить какую-то срочность, но это есть суть - расстановка приоритетов. За спущенные сверху сроки исполнитель не несет никакой ответственности, даже если лично тебе показалось иначе. И в любой непонятной ситуации он назовет тысячи причин, помешавших ему достигнуть желаемого тобой - от проблем со здоровьем до тебя самого, некорректно описавшего задачу.
Только требуя назвать время исполнения, мы заставляем исполнителя декомпозировать задачу и брать на себя ответственность, прикидывать мозгами, а реально ли вообще здесь сделать что-то?
Контролировать
Первоначальная оценка сроков - это, конечно же, важно. Но куда важнее их соблюдение. И тут начинается самое интересное: Люди делают только то, что ты контролируешь.
И это точка. Нет, они, конечно, могут придумывать себе задачи, заниматься креативом, смотреть видео… Но это совершенно не то, чего от них ждёшь ты. Поэтому, самое главное правило для достижения сроков - регулярный контроль их исполнения. Да, это душно. Да, это ужасно. Да, это некомфортно. Но только это работает. По крайней мере, исходя из моего опыта.
Как же всё-таки правильно ставить и соблюдать сроки?
А никак. В идеальном мире любые рекомендации “как правильно” сталкиваются с суровой действительностью. Наверняка, ты задумывался об этом, читая статьи на схожую тематику? “Вот, как у автора всё хорошо! Сделал А, потом Б, записал в В, проконтролировал в Д. Но где же Г?”.
Дело в том, что PM в ходе своей работы сталкивается не с управляемым кодом или красивыми рисунками, а с самым непредсказуемым в природе материалом - людской психикой. Только держа в голове разнообразные хитрости, слабости и приемы уклонения, мы можем если не избежать, но уменьшить фактор риска при срыве тех или иных сроков.
Это значит, что применяемые практики контроля сроков должны сводиться к нейтрализации слабостей конкретных людей и процессов. Исполнитель не умеет объективно оценивать время? - закладываем риск и требуем от него делать оценку почаще (пусть учится). Исполнитель бодро берётся за дело, а потом переключается на другие задач? - постоянно возвращаем его в русло. Исполнитель отказывается от оценки - требуем до последнего патрона (шутка).
До связи!
UPD: В данной статье я не рассуждаю о какой-то конкретной методологии и не перечисляю выдержки из учебников по менеджменту. Всё это - мои размышления о психологии управления. Управления не только программистами (ага, другими людьми тоже порой приходится управлять и там возникают схожие проблемы).
Возможно, для кого-то они покажутся банальными или "нетехническими", а кто-то скажет: что вам, манагерам-дуракам: декомпозировал задачки до уровня часа, в диаграмму всё разложил, графики нарисовал и сиди-кури, всё же написано 100 лет назад. А кому-то, в особенности начинающим руководителям, мои размышления могут показаться вполне себе полезными (мне бы в своё время точно показались).
Никому не навязываю свою точку зрения. Всем спасибо за критику и замечания!
Комментарии (22)
DenisPantushev
22.06.2022 15:18Почему об этом справшивают у работника? На заводе (в нормально производтвенном процессе) этим вопросом занимается экономист и нормировщик. И инструментов у них, чтобы запланировать трудоемкость изготовления детали - множество.От справочников до фотографирования. Виновата индустрия, а не работники. Если бизнес не умеет планировать трудоемкость техпроцесса - это проблема и вина бизнеса.
kukovik
22.06.2022 20:54+1На заводе в работе отсутсвует творческая составляющая. Происходит производство известно чего и известно как. По документации.
Вы сравните лучше с работой конструктора.
DenisPantushev
23.06.2022 06:31+3Ну давайте сравним с работой конструктора. Работал я инженером-технологом. Могу сказать. Никто и никогда не спрашивает ни инженера, ни конструктора, за какой срок он разработает техпроцесс или чертеж. Планированием занимаются начальники бюро и отделов. Они знают и умеют планировать работу бюро и отдела. И методов оценки трудоемкости разработки детали или техпроцесса тоже множество - количество отверстий, количество плоскостей и так далее. Всегда можно оценить сложность детали и привязать к ней трудоемкость. И ответственность за срыв сроков проектирования/отехнологичивания несут начальники (при Сталине их даже расстреливали) - и это правильно. Нигде в промышленности менеджеры проектов, продаваны и прочая бессмысленная братия не насилует работнику мозги насчет сроков, не стоит над душой, не нагоняет стресс на планерках, не подходит и с наездом говорит "что я еще могу сделать, чтобы ты быстрее сделал эту задачу".
Надо сказать прямо и честно. Проблема ИТ в плане планирования сроков и трудоемкости стоит не оттого, что ИТ какая-то особенная сфера, а оттого, что в ИТ доминируют безграмотные кадры, не имеющие высшего технического образования (я имею в виду настоящего инженерного, производственного). Никто из айтишников (я гарантирую вам это!) совершенно не имеет представления о промышленном производстве. Не имеет представления о конструкторской разработке, о технологии. Максимальный потолок для айтишного кадра - радиофак. Большинство же - курсы по джава и спрингу.
О каком планировании может идти речь? Для большинства айтишников (не для производственного инженера!) планирование производства (а разработка софтины в плане планирования производства абсолютно ничем не отличается от разработки ракеты, я гарантирую вам это!) - это магия, тайна, что-то за гранью понимания.
lebedec
23.06.2022 09:16И ответственность за срыв сроков проектирования/отехнологичивания несут начальники (при Сталине их даже расстреливали) - и это правильно.
Знаете почему расстреливали? Потому что акт насилия происходит от бессилия, это крайняя мера, к которой прибегают когда все другие известные способы решения проблемы не получается осуществить.
Работал я инженером-технологом. Могу сказать. Никто и никогда не спрашивает ни инженера, ни конструктора, за какой срок он разработает техпроцесс или чертеж. Планированием занимаются начальники бюро и отделов. Они знают и умеют планировать работу бюро и отдела.
Так умеют, что в советское время создавали целые направления и кружки для изучения и решения проблем менеджмента на производстве. Это всё с тех времен тянется. Познакомьтесь, например, с Щедровицким. Из его лекций можно узнать, что руководители и начальники бюро в принципе не понимали, как строить заводы и управлять производственными процессами в срок.
И что-то мне подсказывает, отсутствие обратной связи и исключение исполнителей из планирования — было одной из причин этих проблем.
lebedec
22.06.2022 15:20+12Как же всё-таки правильно ставить и соблюдать сроки?
Ответ на этот вопрос уже давно дан в книге "Мифический человеко-месяц". Достаточно осознать, что есть два вида сложности задачи: практическая и концептуальная.
Первая подразумевает что решение уже известно, нужно только его исполнить. Это любая работа, для которой уже есть алгоритм или императивная инструкция. Такие работы можно оценить с точностью 100%, их легко автоматизировать, включить в инструментарий.
Вторая подразумевает что решения не существует, его нужно найти. Оценить такие задачи невозможно никакими способами. Потому что оценивать можно только то, что известно. Это, например, новые бизнес фичи, архитектура сервиса или алгоритм обработки данных.
Любую задачу концептуальной сложности можно превратить в задачи практической сложности. Для этого необходимо проводить исследования.
Например. Прежде чем брать новую фичу в спринт, сначала провести системный и бизнес-анализ за фиксированное время. Если задача слишком сложная, этот анализ проводится несколько раз, пока всё же не будет найдено решение. И только потом это решение, декомпозированное на практические задачи, берётся в работу.
Кстати, проводить анализ можно итерациями и по 2 дня, и по 2 часа, смотря к какому темпу готова компания и команда. Так что популярный аргумент “нам некогда, нам бизнес делать надо” не работает.
Если проектный менеджер или тимлид этого не понимает, толкает в работу концептуальные задачи без исследования - никакие средства контроля и самообмана не помогут (кроме везения), сроки будут нарушены.
karambaso
23.06.2022 12:13-1Оценить такие задачи невозможно никакими способами
Возможно. По опыту решения аналогичных задач.
Если проектный менеджер или тимлид этого не понимает, толкает в работу концептуальные задачи без исследования...
Этого не понимает бизнес, а промежуточным элементам это всё доводится в виде ограничений типа бюджета или сроков. Прокладкам не остаётся ничего иного, кроме как транслировать пожелания вниз. Ну или увольняться, что чаще всего не хочется делать.
В целом всё сводится к глобальной оптимизации, в которую как раз наверху никто не умеет (исключительно по системным соображениям). И "Мифический человеко-месяц" здесь ничем помочь не сможет. Это принципиально не его область.
lebedec
22.06.2022 15:26+2Срок, спущенный сверху, НИКОГДА не является зоной ответственности исполнителя
Срок, спущенный сверху, всегда является зоной ответственности исполнителя. Потому что это один из факторов принятия решения. Например, программист может применить готовый проблемный алгоритм, если бизнесу надо завтра, или придумать новый качественный за месяц, если сроки квартальные.
Также зоной ответственности исполнителя является способность дать аргументированный отказ, если сроки неадекватные.
DenisPantushev
23.06.2022 06:51+1Программист должен решать задачу так, как решит руководитель группы. Если исполнитель не укладывается при решении задачи в тот срок, который запланировал руководитель группы - это косяк и ответственность руководителя. Не умеешь планировать работу подчиненных - сдай спецовку.
lebedec
23.06.2022 09:04+1А каким образом, по-вашему, руководитель группы планирует корректный срок для решения задачи?
На мой взгляд, он не может быть экспертом и практиком в той области, которой занимается исполнитель. Поэтому грамотный срок определить он может только на основе показаний исполнителя:
Сделаю за 1 день, но плохо
Сделаю за 2 дня, но потом придётся переделать за 4 дня
Сделаю за 5 дней, но хорошо
Не сделаю, вы требуете невозможного
Поэтому, грамотно обработать спущенный срок в зоне ответственности исполнителя. Я не говорю, что только он за него отвечает, но тоже отвечает, да.
Другое дело, если руководитель игнорирует комментарии и варианты сроков исполнения — это уже неадекватность. В таких случаях свою зону ответственности желательно переводить в другую компанию.
lebedec
22.06.2022 15:43+6Дело в том, что PM в ходе своей работы сталкивается не с управляемым кодом или красивыми рисунками, а с самым непредсказуемым в природе материалом - людской психикой. Только держа в голове разнообразные хитрости, слабости и приемы уклонения, мы можем если не избежать, но уменьшить фактор риска при срыве тех или иных сроков.
Ну да, у программистов послушный компьютер, а у дизайнеров и иллюстраторов красивые картинки. И только у менеджеров другое — у них сложная, непохожая ни на что работа.
Есть целая категория науки, которая занимается проблемами менеджмента — это гуманитарная наука. В неё входит большое количество учебных материалов и исследований по вопросам решения менеджерских задач. Кстати, хитрости, уклонения и манипуляции сотрудниками — не входят в перечень инструментов для решения этих задач.
Только не воспринимайте мои комментарии как нападки.
Мы тут сотни статей пишем о требованиях к навыкам программиста: теория, алгоритмы, разбирайся в бизнесе, умей в софты, организуй свой рабочий процесс, оценки давай для задач.
А для менеджера у нас какие требования? Лояльность, интуиция, пару лайфхаков управления из паблика про менеджмент. Я считаю, что мы должны развеять миф о том, что на менеджера не нужно учится.
karambaso
23.06.2022 12:18+2А для менеджера у нас какие требования?
Одно и очень важное - понравиться нанимателю. Это реально важно для нанимателя. Всё остальное для него - тёмный лес. А система строится именно этими персонажами. Угадайте с трёх раз, какая получилась система.
lebedec
23.06.2022 13:51Да, интересный момент вы затронули.
Но ведь понравится нанимателю может специалист по продажам, или квалифицированный переговорщик. К человеку, который должен уметь управлять производственным процессом это требование не применимо.
А знаете почему так? Потому что в нашем представлении даже чел, который сидит на холодных продажах — тоже "менеджер” по продажам.
Поэтому я и пытаюсь в своих комментариях сделать акцент на том, что менеджер, то есть руководитель — это вполне конкретная специальность, с четкими обязанностями и требованиями к навыкам. А не парень, который приятен для бизнеса в общении.
karambaso
23.06.2022 14:30ПонравитЬся - это комплексная оценка, включающая и субъективное ожидание нанимателя о профессиональных навыках нанимаемого.
руководитель — это вполне конкретная специальность
Не совсем так. Это комплекс, который в нормальной практике разбит на несколько должностей без директивных полномочий. Но общепринятая практика подсказывает очередному "руководителю" - властью нельзя делиться. Тем более, вообще её лишаться. Наниматель этот мотив отлично понимает, ибо сам в точно такой же роли. То есть смысл опять в системе.
AleksandrSergeichuk
22.06.2022 18:02+1Короткий ответ - декомпозировать, учитывать риски с зависимостями, обсуждать задачу с исполнителем
Так то техник как оценивать и попадать в оценки неприлично много и большинство из них рабочие
Aquahawk
22.06.2022 19:08-1Оценку данную техническим специалистом, в случае если бизнесу нужна оценка сверху, нужно умножать на Pi с округление вверх и с переводам в следующую единицу измерения времени.
Сказали будет через 15 минут, умножаем на pi, получаем 47.1 округяемм вверх, получаем 48, минуты меняем на часы, 48 часов. Вполне реальный срок. 2 дня? 7 недель. Три недели? 10 месяцев.
Ну а дальше искуство не просрать задачу и сделать быстрее.
Nialpe
22.06.2022 19:11+3Почему не работают? Потому, что на оценку необходимо время. И чем сложнее задача, чем хуже она описана, тем больше времени требуется. А времени на оценку не предусмотрено в бюджете. Так и живем, к сожалению.
DenisPantushev
23.06.2022 07:09В промышленном производстве оценкой времени занимаются нормировщики и экономисты. И все прекрасно работает. И только в айти полная ахинея.
kresh
22.06.2022 21:06Какое совпадение, как раз сегодня Fermat's Library прислали статью THE MYTHICAL MAN-MONTH.
OlegZH
22.06.2022 21:31+5Можно попробовать порассуждать. На заявленную тему.
Предположим, у нас есть модули, решающие отдельные задачи. Скажем, конвертирование файлов или представление результатов запроса к базе данных. Всё это — задачи, допускающие явную оценку времени реализации. Нижняя оценка — для высококвалифицированного программиста, и верхняя — для низкоквалифицированного.
Более крупные задачи решаются при помощи декомпозиции на более мелкие. Линейная декомпозиция означает, что модули собираются в цепочки. Имея K модулей, можно собрать цепочку, у которой будет K+1 точка сочленения (включая точку входа и точку выхода). Соответственно, всего будет 2K+1 точка приложения сил. Добавление в цепочку ещё одного модуля приводит к появлению трёх новых точек сочленения. И это всё — в самом простом, линейном случае!
Ещё бывает пространственная декомпозиция, когда имеются модули, которые имеют в системе различное назначение, или компоненты. Реберное представление графа взаимосвязей компонентов даёт оценку трудоёмкости реализации сложной системы.
Но! Декомпозиция бывает ещё и в иерархическом плане, когда имеются различные слои реализации.
Видимо следует понимать, что основная технологическая причина затягивания сроков заключается в том, что вот эту самую слоистость и многоуровневость игнорируют. Как только приходится делать шаг в новое измерение, происходит "комбинаторный взрыв". Что было бы, если бы даже при создании даже относительно простых приложений создавались (бы) все необходимые слои, модули и компоненты? (Даже если они довольно простые. )
Что это всё означает? А то, что, когда разрабатывается какая-то система, необходимо заранее определить класс этой системы, то есть — выбрать количество слоёв, определить архитектуру каждого слоя и задать зависимости между слоями. С каждым классом системной сложности связано и своё время реализации. Но тогда у клиента/заказчика будет список вариантов, где описывается, что вот такая-то система такого-то класса реализуема за такое-то время. Тогда появляется выбор. Либо такая-то более простая система "здесь и сейчас", либо более сложная система, тогда-то и тогда-то. Проблема в том, что как-только делается выбор, этот выбор должен быть реализован в полном объёме. Это и есть ответственность. А кому хочется нести ответственность?
При этом, надо понимать, что нельзя просто так ввести новое требование. Нельзя просто так взять более простую систему, что-то в неё добавить, и предъявить новый релиз. Новый релиз должен делаться с самого начала и до самого конца. Любая заплатка, костыль или переходник опять же провоцируют комбинаторный срыв сроков. Нельзя рассчитывать на высококлассного специалиста, который может составить чёткий план перехода к новому релизу в своём воображении и также чётко и без ошибок реализовать этот план.
Тут есть ещё один немаловажный аспект. Представим, что собирается новая команда разработчиков. В обычной ситуации, эта команда как можно скорее берётся за первое попавшееся дело, чтобы заработать денег, основать репутацию и притереться к друг другу. Команда, однако, может поставить для начала некоторые внутренние задачи. Например, команда может рассмотреть задачи из своей предметной области, заранее произвести их декомпозицию и реализовать базовую библиотеку для всех своих будущих проектов. Понятное дело, что в терминах этой библиотеки длительность реализации любого потенциального продукта может быть оценена с довольно высокой точностью. Отсюда и адекватный ценник на услуги, который будет представлять в таком случае шкалу увеличения системной сложности, чтобы клиент, приходя за решением конкретной задачи, заранее знал, в какую историю он ввязывается. Но такую работу никто никогда не оплатит. В результате, наука — отдельно, а практика — отдельно.
Так и живём.
А про оттяжки и проволочки ещё классик (не помню какой, у Дейтела в древней книжке по операционным системам было) сказал:
Оттяжки и проволочки — самая тяжкая форма отказа.
1Tiger1
24.06.2022 04:22А мне нравится вывод в конце, действительно никак. А знаете почему никак? А потому что люди часто путают сроки, время, приоритет, планирование, стоимость и обещание заказчику. Смешивают это все вместе, называют "оценкой" и страдают. В статье я тоже эти страдания наблюдаю. А это ведь разные вещи, с разными целями. Срок может бить привязан бизнесом к какому-то событию, которое сложно сдвинуть, дедлайном называется. Настоящим, а не тем который придумывает плохой PM чтобы красиво закрыть месяц или другой период. Таким дедлайном нарушение которого бьёт по бизнесу. Иногда его даже оценивать не надо, он уже на момент оценки известен. Но иногда спрашивают и учитывают, тогда оценивать надо, вместе, ведь ситуация не частая но впжгая, так что все заинтересованные на колл и оцениваем все риски.
Время - ну тут в нас предполагаемое время на реализацию. Чистое, не привязанное к календарю, может растянутся если вдруг появится срочные задачи а эту отложить. Удобно чтобы прикинуть загрузку и в целом при планировании. Ааа оценивать - спросить разработчика. Плохо оценивает разработчик - скрам покер вам в руки. Риски? А так ли они важны для этой задачи? Компенсируют я другими оценками, можете заложить общею рисковую зону если хотите выполнять все по плану. Но и те если это вам реально нужно.Приоритет - вот истинный инструмент менеджера. То что позволяет вам не погрязнуть в мелочах и сфокусировать продукт на важном. И всем остальным удобно. У приоритетов врожденный иммунитет к рискам и ошибкам оценки, по умолчанию. Они им просто не нужны. Кто оценивает - заказчик, вы, продукт, ну кто определяет курс продукта тот и оценивает. Ну тех специалиста можно позвать для зависимостей. Тут главное ведь что - назначил приоритет - не меняй, без чезарды в духе "это срочнее а это приоритетнее".
Планирование - ну то есть еценить так чтобы вы потом ганта красивого составили, с числами и загрузкой, все плотненько и красиво, а риски как то в задачу заложить чтобы вот ровно столько заняла сколько оценили. Ну вы в курсе, так не бывает. Поэтому аджайл и используют. И вам тоже скорее всего он пригодится. Только не уродуйте его до состояния "спринт, планирование, демо, остальное вырезаем". Примите неопределённость, осознаете невозможность строгого планирования, смиритесь и признайтесь себе что оно не так важно как вы думали, и обретете покой и гармонию.
Стоимость. Ну там же дело не только во времени программиста, особенно если вы не аутсорсеры. Да даже если и аутсорсеры, а так ли нужны заказчику стоимости каждой задачи? Может он просто так привык? Может ему достаточно грубой оценки в стори поинтах чтобы просто не пускать в работу мелочь которая будет стоить много? Абстрактно много, без привязки а валюте. Вы говорили с ним об этом? Может и ему этот хаос не нужен и он будет просто платить по dedicated team?
Ну и наконец то что встречается на самом деле и чпще всего, его величество обещание. Мы сделаем этот пакет задач к этому сроку и ни днем более . Для этого мы потратили кучу времени на оценку и зависимости, заставили вас детально сейчас продумать задачи и рассказать, даже если вы сами ещё не уверены нужна ли фича и в каком виде, нвбросили сверху рисков, потом нвбросили ещё фикс 30% на риски, отдаём вам план и общение, вот вам ещё и ганта вприлачу, чтоб красиво. Ну а вы передадите на уровень выше. И мы знаем что вам это не особо и нужно, и на уровнях выше точность до дня или нескольких на а не сдалась, и ничего срочного в этих задачах нет, и нам будет неудобно, и рисков мы наьроспли по самое нихочу из-за чего роадмапы далеки от оптимальных а цены конские, и программисты да и все мы будем в стрессе чтобы доставить к нужному сроку вот этот ничем не примечателтный в плане срочности пакет задач (мы ведь с вами знаем что реально срочеып пойдут вне пакета и поломают нам все планы и добавят стресса), но все мы будем играть в этот театр, ведь кака же без планов, для чего-то же нужны менеджеры, а диаграммы ганта красивые. На тут вы поняли, через море сарказма я пытался донести мысль "сроки и планы нужны только если они реально обоснованно нужны, иначе это гора геморроя, стрессы и падение эффективности просто так, чтобы отчетик нарисовать".
Короче определитесь что оцениваете, настройте процессы соответственно, поговорите с начальством и заказчиком, о том что реально нужно, и помните 3 максимы:
процесс, планирование, оценки - все это только инструменты для решения задач.
вы машете инструментами и затачиваете их под задачу, а не они управляют вами и задачами. Жертвы бессмысленных процессов, очень печальное и распространённое зрелище.
не усложняйте. Вот совсем. Режьте бритвой оккама все что можно, любую лишнюю активность, планируйте только то что нужно, закладывает риски только если они важны, ставьте дедлайны только тогда когда их нарушение будет огромной проблемой, работайте приоритетами а не календарём, календарь слишком не надёжная штука чтобы на него рассчитывать.
usego
>а с самым непредсказуемым в природе материалом - людской психикой
Ну да, опять люди виноваты. Очень многие задачи реально находятся в плоскости не то что "хз сколько времени это займёт", а даже в плоскости "хз как это вообще делать", независимо от квалификации. Новые библиотеки, новые подходы, да даже копипаст не всегда копипаст, а куча сюрпризов в процессе реализации, как технических, так и в BL. Со временем на оценки тупо забиваешь, ибо бесмысленно всё это и ты всегда крайний. Понятие Pocker game не даром появилось. И, упаси хосподь, Agile как таковой.