Сегодня многие говорят и пишут об особенностях работы (и её поиске) в кризисное время. Мне не нравится слово "кризис", поэтому я его использую только в начале этого поста, и только ради индексации в поисковиках по этому ключу :)
Больше ни слова про слово на "К" ;) Дальше только про новые возможности!
Сейчас пришло время, когда есть повод пересмотреть свои старые договорённости: компании задумываются о необходимости удержания своих сотрудников, сотрудники подумывают о комфорте работы в своих компаниях, заказчики начинают искать варианты закрытия контрактов со своими старыми подрядчиками, подрядчики начинают сомневаться в выгодности исполняемых заказов...
Все что-то переваривают, о чём-то усиленно думают. Сегодня появился повод сослаться на "К" и под этим предлогом сменить условия сотрудничества.
Мне хочется назвать это время "временем переосмысления". Что за прекрасное время! Давайте же использовать его потенциал!
Основная часть
Сегодня как никогда важно быть эффективным. Продуктивным быть уже недостаточно. Недостаточно писать много кода. Недостаточно повышать метрики производительности команд. Недостаточно часто выпускать релизы.
Сегодня важно эффективно реализовывать наиценнейшие потребности бизнеса в наикратчайшие сроки с наивысшей адаптивностью к изменчивым потребностям рынка. И тот, кто докажет, что на это способен - сделает сверхскачёк.
Давайте рассмотрим суть происходящего по порядку.
Удовлетворение найценнейших потребностей бизнеса
Отчёт Standish Group за 2002 год (так называемый"Chaos Report") утверждает, что в любом программном продукте общего пользования порядка 2/3 функционала не используется либо используется редко и лишь 1/5 используется всегда или часто.
С трудом верится. Но если вы подумаете о своих продуктах (если вам приходилось участвовать в разработке ПО), то вы легко сможете идентифицировать ряд фич, без которых ваш продукт остался практически таким же полезным как и с ними... Я проводил на тренингах подобное упражнение с участниками, большинство с лёгкостью в течение 7 минут выписывает 5-10 относительно больших фич, которые можно было не реализовывать. На вопрос, почему они говорили об этом заказчикам, половина отвечала: "а зачем?"...
Если верить этому же отчёту, более половины проектов в 2004 году переиспользовала свой бюджет и при этом более 80% проектов не уложились в срок. И всё это при том, что в этих проектах было в среднем 2/3 неиспользуемых фич.
Если верить этому же отчёту, более половины проектов в 2004 году переиспользовала свой бюджет и при этом более 80% проектов не уложились в срок. И всё это при том, что в этих проектах было в среднем 2/3 неиспользуемых фич.
(пауза)
...В наикратчайшие сроки
Это не означает выпустить полную версию уже завтра или послезавтра. Нет. На столько быстро мы писать вряд ли сможем писать код (there is not silver bullet...).
...В наикратчайшие сроки
Это не означает выпустить полную версию уже завтра или послезавтра. Нет. На столько быстро мы писать вряд ли сможем писать код (there is not silver bullet...).
Но посмотрите на эту иллюстрацию:
Производительность обоих проектов одинакова: обе команды за одинаковое время выпускают 100 единиц ценностей (business value, BV).
Но при каком из этих подходах выпуска BV заказчик более спокоен? Что заказчик понимает под найкратчайшими сроками? Выход финальной версии (когда-нибудь) или выход ранних рабочих версий (уже сейчас)?
При каком подходе заказчик раньше начинает получать (видеть) выгоду от вложений?
Так уж важны ли заказчику финальные сроки, если он каждые две недели может получать готовую к поставке версию продукта?
При чём, у него есть возможность остановить разработку в любой из этих точек: "всё, хватит, сыт" (инвестиции перевешивают выгоду).
Производительность обоих проектов одинакова: обе команды за одинаковое время выпускают 100 единиц ценностей (business value, BV).Но при каком из этих подходах выпуска BV заказчик более спокоен? Что заказчик понимает под найкратчайшими сроками? Выход финальной версии (когда-нибудь) или выход ранних рабочих версий (уже сейчас)?
При каком подходе заказчик раньше начинает получать (видеть) выгоду от вложений?
Так уж важны ли заказчику финальные сроки, если он каждые две недели может получать готовую к поставке версию продукта?
При чём, у него есть возможность остановить разработку в любой из этих точек: "всё, хватит, сыт" (инвестиции перевешивают выгоду).
Выпускать в найкратчайшие сроки не означает отгружать рабочий продукт быстро. Это означает возвращать инвестиции заказчика постоянно.
С наивысшей адаптивностью
Когда вы заказчик может не только изменять и но выстраивать свои желания, основываясь на опыте работы с вашим приложением и вами, тогда рождаются более интересные, смелые и удобные решения.
Чем выше частота обратной связи - тем выше адаптивность. Есть множество способов внедрить циклы обратной связи в ваши проекты. SCRUM - по сути это интегрированных подход внедрения таких циклов.
Итог
Нынешнее время предоставляет уникальные возможности изменить ваши условия труда. Сломать зависимости. Попробовать нечто новое. Перейти на новый уровень.
Не бойтесь! Вперёд!
Удач
