Comments 20
>>Зачем опаздывают проекты?
Чтобы люди без работы не оставались).
Чтобы люди без работы не оставались).
Собственно это и есть третья ситуации. Для многих — завершить проект означает стать безработным. Особенно если проект был долгим. Безработным быть страшно.
Завершить проект — значит получить результат.
Тут есть фундаментальный страх: «А вдруг не получится?»… и еще более злобный «А вдруг получится?».
В коучинге их называют гремлинами (вредными маленькими зелеными человечками шепчущими на ухо, да:). Пришедшего гремлина замечаем, говорим «привет мой друг!», записываем в дневник «сегодня в обед опять приходил „а вдруг не получится“». И гремлин теряет силу :)
Тут есть фундаментальный страх: «А вдруг не получится?»… и еще более злобный «А вдруг получится?».
В коучинге их называют гремлинами (вредными маленькими зелеными человечками шепчущими на ухо, да:). Пришедшего гремлина замечаем, говорим «привет мой друг!», записываем в дневник «сегодня в обед опять приходил „а вдруг не получится“». И гремлин теряет силу :)
Мне кажется, самые долгий и сложный этап в любом проекте — это между 95% и 100%.
Эти несчастные пять процентов — это какой-то магический психологический барьер и с ним нужно всячески бороться.
Эти несчастные пять процентов — это какой-то магический психологический барьер и с ним нужно всячески бороться.
Олимпиада началась без задержек, в остальном согласен.
UFO just landed and posted this here
У большинства проектов нет никакой необходимости делать строгий срок сдачи. Скорее, есть набор функций, который хочется реализовать. Необоснованная дэдлайн-ориентированность часто приводит к тому, что этот срок игнорируется разработчиками.
В общем случае разработчик не может сделать указанную работу за отведенное время. Он может сделать или определенную работу, или уложиться в определенное время. Задачи дискретны, взаимосвязаны и важны. Время непрерывно и (чаще всего) не так важно. Поэтому сроки затягиваются.
В общем случае разработчик не может сделать указанную работу за отведенное время. Он может сделать или определенную работу, или уложиться в определенное время. Задачи дискретны, взаимосвязаны и важны. Время непрерывно и (чаще всего) не так важно. Поэтому сроки затягиваются.
Я бы сказала так. Опаздывают проекты тогда, когда это можно сделать.
Мы можем видеть рационально, что причины, описанные выше, можно назвать психологическими. Если у нас есть конкурент и нам необходимо выпустить быстрее, продукт выйдет даже полу готовый, но чтобы выйти. А когда спешить незачем, можно и лямпу потянуть.
Мы можем видеть рационально, что причины, описанные выше, можно назвать психологическими. Если у нас есть конкурент и нам необходимо выпустить быстрее, продукт выйдет даже полу готовый, но чтобы выйти. А когда спешить незачем, можно и лямпу потянуть.
А вам не кажется, что формат выпуска «как есть» несколько расхолаживает? Я согласен, что не всегда нужно искать идеал и шлифовать, полировать до самого что ни на есть блеска. Но в некоторых случаях выпускать полный шлак на рынок бессмысленно, а иногда действительно в процессе работы выясняются такие подробности, которые требуют доработки.
Здесь вспоминается методология военных разработок: всё регламентируется ГОСТами. Вид работы, как следствие количество этапов, требования к ТЗ на каждый этап и требование отчётности за каждый этап. Есть эскизный проект, есть технический (а иногда они взаимозаменяются), есть рабочая КД, есть макеты, есть серия…
Для мелких проектов нагромождать всю эту бюрократию не стоит, но раз уж возник вопрос «Зачем проекты тормозить», значит нужно регламентировать работу, а не просто размышлять умные мысли :) Потому что мысли-то по разную сторону баррикад у всех разные — а ГОСТ един!
Здесь вспоминается методология военных разработок: всё регламентируется ГОСТами. Вид работы, как следствие количество этапов, требования к ТЗ на каждый этап и требование отчётности за каждый этап. Есть эскизный проект, есть технический (а иногда они взаимозаменяются), есть рабочая КД, есть макеты, есть серия…
Для мелких проектов нагромождать всю эту бюрократию не стоит, но раз уж возник вопрос «Зачем проекты тормозить», значит нужно регламентировать работу, а не просто размышлять умные мысли :) Потому что мысли-то по разную сторону баррикад у всех разные — а ГОСТ един!
Если надо добавить функциональность — надо добавить сроки.
Полностью с вами согласен. Но опытные участники проекта знают, что в проекте будут непредвиденные вещи — ошибки архитектуры, новые технологии, требующие дополнительных исследований и т.д. И соответственно закладывают это в сроки проекта. Я полностью поддерживаю идею творческого поиска и отнюдь не предлагаю снижать качество — есть мастфиксы с которыми выходить нельзя. Но по-моему опыту существенная часть «доделок» не повышают, а снижают качество проекта. Знаете — как ребенок напяливает на себя слишком много украшений. Мое мнение — если после трех иттераций продукт все еще не удовлетворительный — лучше начните сначала.
Тут проблема в другом. Какой продукт мы делает. Если это сервис, который на лету, получая feedback, мы можем доработать. То лучше его выпустить на рынок раньше. Если это какой-то гаджет или еще что-то, мы можем морально устареть.
Выпуск продукта это почти всегда затраты на маркетинг и/или на производство. И не выпустить гаджет зачастую выгоднее, чем выпустить. И с моральным устареванием согласен — поэтому заново надо делать уже что-то другое, старое-то не получилось. Но обычно и команде и инвестора настолько жалко терять вложенные силы и деньги, что они готовы терять еще и еще лишь бы не признаваться в провале.
Есть еще одна причина опозданий: чтобы получить заказ продавец с руководителем занизили сроки на реализацию. И благодаря этому получили деньги и бонусы для себя. И тут особо ничего не сделаешь.
UFO just landed and posted this here
Вопрос почему — это вопрос о причинах, вопрос зачем — это вопрос о целях. При все похожести это очень разные вопросы. Почти бесполезно бороться с причинами, если цели остаются прежними.
Спросите себя — что мешает всем участникам проекта согласиться с тем, что будут случайности и излишний оптимизм и заложить эти сроки в проект?
Конечно в основном статья ориентирована на IT проекты (как никак хабр), но пример из моей консалтинговой практики: крупный девелоперский проект в Москве. Стоимость проекта переваливает за 200 кк долларов. Две недели до сдачи проекта. Глава архитектурного совета компании приезжает на объект — в результате переделывается вся гранитная облицовка (разумеется утвержденная до этого) так как по мнению главы не подходила по цвету. Или проект подготовки документации по ЦТО в атомной электростанции — который делался на 3 месяца дольше, так как проектировщики решили вдруг добавить туда несколько новых решений.
Спросите себя — что мешает всем участникам проекта согласиться с тем, что будут случайности и излишний оптимизм и заложить эти сроки в проект?
Конечно в основном статья ориентирована на IT проекты (как никак хабр), но пример из моей консалтинговой практики: крупный девелоперский проект в Москве. Стоимость проекта переваливает за 200 кк долларов. Две недели до сдачи проекта. Глава архитектурного совета компании приезжает на объект — в результате переделывается вся гранитная облицовка (разумеется утвержденная до этого) так как по мнению главы не подходила по цвету. Или проект подготовки документации по ЦТО в атомной электростанции — который делался на 3 месяца дольше, так как проектировщики решили вдруг добавить туда несколько новых решений.
Sign up to leave a comment.
Зачем опаздывают проекты?