Как я могу отстаивать полужесткий график выпуска в среде, не склонной к риску?

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

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

Я ищу убедительные аргументы, чтобы убедить руководство, не склонное к риску, что:

1. Команда разработчиков должна (или должна) иметь возможность устанавливать собственный график выпуска - в пределах разумного (конечно, 1-3 месяца должны быть достаточно консервативными для всех, кроме крупнейших компаний из списка Fortune 500);

2. Выпуски программного обеспечения являются важными вехами, и к ним не следует относиться кропотливо; другими словами, ненужные задержки / остановки очень разрушительны и должны рассматриваться только как последнее средство решения некоторой критической проблемы бизнеса; и

3. Внешние (не разработчики / не-ИТ) организации, которые хотят (или требуют) участвовать в качестве заинтересованных сторон, обязаны сотрудничать с командой разработчиков в целях соблюдения графика выпуска, особенно в последнюю неделю или около того перед запланированной поставкой дата (т.е. пользовательское тестирование / постановка).

Выше приведены утверждения, которые звучат правдоподобно для меня, основываясь на опыте, но похоже, что теперь я в состоянии доказать это - поэтому я прошу кое-что немного более здесь, если такая вещь существует.

Может ли кто-то, кому приходилось «продавать» идею фиксированного (или, может быть, полугибкого) цикла выпуска руководству, дать несколько советов о том, какие аргументы / стратегии эффективны или убедительны, а какие нет? Помимо очевидного несогласия с графиком и неоправданных затрат, существуют ли какие-либо достоверные данные / доказательства, которые были бы полезны для обоснования того, что доставка действительно важна даже в «корпоративной» обстановке?

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

_{Обратите внимание, что мы организовали релизы, и это проходило на всех этапах, кроме производства. Проблемы отслеживаются с помощью коммерческого средства отслеживания ошибок, и каждая проблема - 100% из них - которая была назначена этому выпуску, была закрыта. Я понимаю, что в это трудно поверить, и в этом-то и заключается суть - нет смысла, что 100% полнофункциональный, полностью протестированный, одобренный заинтересованными сторонами выпуск будет отложен руководством по необъяснимым причинам, но это то, что произошло, это то, что происходит, это проблема, которую нужно решить.}

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

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

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

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

Все эти затраты на развертывание могут легко превзойти стоимость просто разработки программного обеспечения. Мудрая команда управления проектами делает все возможное, чтобы планировать, планировать и планировать все эти вещи. Вы сделали эту работу? Вы дали понять руководству? Если нет, то возможно, что они будут медленными в ваших развертываниях.

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

Также возможно, что ваша управленческая команда не работает. Ваша команда разработала что-то, чего не хочет остальная часть компании? Твой новый материал угрожает черту твоей команде по продажам или производству? Если это так, какой-то руководитель может торпедировать его, говоря, что это слишком рискованно, чтобы его развернуть. Вы ничего не можете с этим поделать, если вы не генеральный директор.

Вы попросили убедительные аргументы для своевременного развертывания программного обеспечения. Есть один действительно убедительный аргумент: возврат инвестиций. Компания решила инвестировать в это программное обеспечение, и теперь они решили потратить впустую инвестиции, поскольку ваше программное обеспечение медленно гниет на полке.

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

Сначала посмотрите это видео:

http://the99percent.com/videos/5822/Seth-Godin-Quieting-the-Lizard-Brain

Управляющее резюме:

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

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

Вы излечиваете побои, заставляя людей делать это в начале цикла разработки продукта , а не в конце.

Внесение изменений в продукт за несколько недель до даты выпуска по очень понятным причинам очень разрушительно. Это верно, независимо от того, является ли изменение новой функцией, изменением процесса разработки программного обеспечения или попыткой исправить давнюю ошибку, которой нет в расписании разработки.

Когда кто-то приходит ко мне за исправлением или изменением в конце цикла разработки, я всегда спрашиваю его: «Что вы хотите, чтобы я не сделал, чтобы я мог выполнить вашу задачу?»

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

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

Это звучит очень похоже на проблему «способность против желания», у вас есть желание отпустить, но нет возможности (авторитета), у тех, у кого есть власть, нет желания.

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

Я также подозреваю, что между участвующими сторонами существует небольшое уважение, поэтому разумных обсуждений со взрослыми не происходит.

Извините - не конкретный ответ, который вы просили, но, надеюсь, несколько вещей, чтобы подумать.

Первое, что нужно учитывать, это убедиться, что ваши релизы не подвержены высокому риску .

В идеале, ваши запросы на изменение должны иметь раздел под названием « Снижение риска» , содержащий инструкции о том, как выполнить откат к предыдущей версии, если что-то пойдет не так. С точки зрения риска, никакое предварительное тестирование не может заменить простой вариант отката изменения.

• ^{В среде, не склонной к риску, я не могу представить способ сделать необратимые изменения безболезненными.
  Если многие / большинство ваших выпусков попадают в эту категорию, вы можете пересмотреть свою архитектуру.}

Риск не отпуская должен быть разоблачен, если вы хотите DEV график команды , которые будут относиться серьезно.

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

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

• Проще говоря, парням, блокирующим ваш релиз, XXнужно знать не только о том, что они рискуют Nостаться нерешенными, но и через неделю (или месяц) у них будет релиз XX+1в очереди на утверждение, блокировка которого будет Риск возникновения N+Mпроблем с производством остается нерешенным - и это также будет иметь место с XX+2последующими «внутренними» выпусками, предоставленными командой разработчиков.

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

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

• ^{«... рекомендуем рассмотреть возможность обновления приложения до более новой версии ( XXили более поздней). Тот, который в настоящее время развернут в вашей среде ( XX-2), сильно устарел - два основных выпуска за текущей базой кода. В результате подробности о таких простых ошибках Приложение скрыто в журналах, а приложения для клиентов сообщают о неразборчивом мусоре вместо четких описаний сбоев, что приводит к тому, что пользователи и поддержка тратят время на изучение действительно простых проблем ».
   
  Выше был добавлен комментарий, который я добавил некоторое время назад в службу поддержки проблем для заявки. связанные с конкретным производственным инцидентом. Вскоре после этого «заинтересованные стороны» связались с командой разработчиков, чтобы узнать, как отслеживать наши релизы и как они могут помочь в развертывании в их среде. Ох, и они также быстро обновились сXX-2версия тоже. :)}

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

Одна вещь, которую вы найдете полезной, - это выбрать и отследить, кто отвечает за конкретное проскальзывание релиза. В принципе, вы должны быть в состоянии быстро и четко ответить на вопрос типа «кто несет ответственность за то, что запланированного выпуска не произошло?» Если вы не готовы, они могут выбрать путь наименьшего сопротивления и возложить вину на вас. Как указано в комментариях к другому ответу : «Вы можете оказаться в горячей воде, от которой ваше руководство пытается вас защитить».

Последнее, но не менее важное,

это займет время

(вы, вероятно, уже знаете это, но, похоже, стоит заявить об этом явно)

То, что вы ищете, можно охарактеризовать как изменение отношения: от «рискованно освобождать » до «рискованно НЕ выпускать ». Изменение отношения редко случается в одночасье, может потребоваться терпение, чтобы завершить смену.

Над вашим вопросом стоит большой знак вопроса, и поэтому ваша компания не хочет выпускать программное обеспечение. Это не всегда простой случай неприятия риска. Часто есть другие причины, лежащие в основе, которые не часто передаются с высоких управленческих высот. Поэтому мой вопрос к вам: «Вы сели с вашим боссом и спросили его, почему задерживается выпуск продукта?».

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

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

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

Еще одна вещь, о которой я только что подумал и которая может вам чем-то помочь, - это, возможно, прочитать Lean Software Development и посмотреть, есть ли там что-нибудь ценное, что может иметь отношение к ситуации в вашей компании, особенно в первых нескольких главах. Я думаю, что это была глава 4, в которой обсуждается проблема доставки как можно быстрее, и есть что-то, связанное с задержкой затрат.

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

но в реальном мире реальный выпуск - это проблема кого-то другого, вы должны отправить его им, а затем воспринимать как релиз. Как только он вышел из вашей двери, он отправлен. Если они просто сидят на нем, это не ваша проблема (на самом деле, это здорово, об этом не сообщается об ошибках! W00t! Бонусы за релиз без ошибок со всех сторон;))

В любом случае, вам нужна система контроля изменений и менеджер релизов. Тогда все просто (за исключением того, что вам нужно управлять управлением изменениями, поэтому очень важен контроль версий и сборки развертывания. Это требует организации, но если вы организованы, это легко).

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

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

Ты пробовала:

1. Спросите руководство, чтобы клиент или группа клиентов действовали как заинтересованные стороны в процессе разработки? Обычно вы можете найти одного покупателя, который будет принимать промежуточные версии и давать отзывы. Они могут быть отличными защитниками, когда пришло время выпустить. Даже «ограниченный выпуск» для одного клиента может быть достаточным, чтобы помочь руководству
2. Построение плана выпуска, включая точечные релизы. То есть вы можете выпустить 3.4 сегодня, потому что релиз 3.4.1 запланирован на сегодня + 1 месяц. Это вместе с хорошей идеей, которую вы уже упоминали, что каденция релиза помогает этому сообщению.
3. Получите поддержку, продажи или маркетинг на вашей стороне. Внесите исправления, которые позволят решить 3 самых популярных запроса в службу поддержки, и вы сможете получить союзника из другого отдела. Если вы не можете получить заинтересованную сторону клиента, как в # 1, попробуйте это с несколькими продавцами. Предложение быть доступным для встреч по продажам и взять с собой продукт. Когда вы в пути, покажите продавцу, что вы работаете с продуктом (в каком бы состоянии он ни находился), чтобы он потянул вас за собой.

Чтобы ответить на ваш другой вопрос о том, «почему руководство будет сидеть на выпуске?» Компании делают это все время в не связанных с SW областях, и я не думаю, что это беспрецедентно. Например, у вас есть новый релиз, который готов к работе, все протестировано и готово. Но старая версия еще не была вытеснена конкурентами. Как только конкуренция выпускает конкурирующий продукт, то есть старую версию, руководство выпускает версию, ожидающую на полке, и разрушает рынок, сдерживает конкуренцию и поддерживает продажи и репутацию лидера рынка. Выпуск слишком рано дает советы конкурентам, которые могут лучше понять вашу дорожную карту и попытаться победить вас в финале.

С учетом всего сказанного ... Бритва Ханлона, вероятно, правильный ответ :-)

Уйдите от этой компании, они не понимают программного обеспечения. А если серьезно, программное обеспечение - это то, что заставляет систему работать, представьте, если бы вы делали машины, машины медленные? они ждут релизов автомобилей? Они инкрементные и бюрократические? Нет, они стараются делать вещи максимально быстрым и чистым способом. У вас есть проблема с управлением, и вы должны работать над ней как с конфликтом управления, попытаться выразить их в их терминах. Спросите, что для них значит риск, затем постарайтесь свести его к минимуму. Чувства ваших разработчиков также важны, так как они должны справляться с решениями, которые будут приняты вашим вмешательством. Будут ли они счастливы делать все ночи, чтобы отправить вовремя? Какими будут призы / штрафы? И т. Д. Теперь я дам вам практический подход к этой проблеме, немного экстремальный, но попросить аудита.