Как стать автором
Обновить

Комментарии 7

При этом, в повседневной жизни люди прекрасно справляются с планированием. Например, не опаздывают на самолет. 

У меня ни разу не было такого, чтобы я планировал успеть на самолет к 15 часам, и был готов к тому что возникнет пробка, однако оказалось что пробка на конкретном участке МКАД устаревшей версии, если её апдейтить то аэропорт пропадает полностью и вместо него пустое поле, а если не апдейтить то при стоянии в пробке больше часа вылетает таймаут....

Я удивляюсь, как можно писать о планировании работ, и вообще не упомянуть диаграмму Ганта? То есть, вы планируете, планируете - и даже не представляете, какие у вас зависимости между задачами? И даже не пытаетесь визуализировать, где у вас критический путь? И применить готовый софт типа MS Project, который вполне может учитывать многие упомянутые параметры.

  • Определить зависимости между стадиями, спланировать параллельную работу с учетом этих зависимостей.

Ну т.е. вот же, прямо оно. Неужели сейчас этому вообще не учат (меня этому учили в институте, причем я учился на инженера)?

разработчик не знает, что такое Гантт, например. У него все зависимости в трекере проставлены)

а статья вполне работает для всех, кто дает сроки

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

Диаграмма Ганта, книги Голдратта и т.д. - это важно, но я хотел рассказать наиболее просто. И чтобы применить можно было даже к небольшой задаче. Ведь там тоже часто бывают промашки по срокам. Я не думаю, что софт типа MS Project стоит использовать, когда разработчику надо назвать срок готовности фичи, состоящей из трех-пяти задач.
Да, какие-то моменты в статье были под чуть больший масштаб, на вырост. Но я думаю это неплохо, когда логика планирования прозрачна для всех участников команды.

Если же планирование является основной работой, как, допустим, у проджект-менеджера, то врядли ему поможет статья типа этой

хорошая статья, че минусуют? Все по делу. немного много букв, но кто сможет дочитает и сделает хотя бы половину из написанного, получит профит :)

про самолет образ понравился. Главное в неопаздывании на самолет - это как часто вы им летаете. Было время, я все время летал. У меня была сумка, которую я мог собрать за 10 минут - и я на пути в аэропорт. Аэроэкспресс по расписанию, контроль - точно к посадке, чтобы было не надо ждать и захожу последним, чтобы не топтаться в рукаве.

Все было рассчитано точно, до копеечки. И достигнуто было, увы не теорией, а только практикой. Вот и учи разработчиков и менеджеров не опаздывать теперь. Учу учу, а все равно продалбывают :)

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

В разработке же мы довольно часто встречаемся с задачами, где порой не очень понятно под какие риски закладывать буферы и вообще какие риски сыграют роль в процессе реализации. При этом оценка первоначальная всё же ожидается, иначе, процитирую: а как тогда анонсировать фичи клиентам, заключать контракты... .

Хорошей практикой является, по возможности, давать оценивать задачи тому что ближе и лучше знаком с её контекстом, подводными камнями и у кого более полная картина о том что нужно вообще будет сделать.

Хорошей практикой является, по возможности, давать оценивать задачи тому что ближе и лучше знаком с её контекстом, подводными камнями и у кого более полная картина о том что нужно вообще будет сделать.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории