Як я можу виступати за напівстрогий графік випуску в умовах, що не мають ризику?

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

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

Я шукаю переконливих аргументів, щоб переконати менеджмент, який не підтримує ризик, що:

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

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

3. Зовнішні (не-розробники / не-ІТ) суб'єкти, які хочуть (або вимагають) бути залученими як зацікавлені сторони, несуть відповідальність співпрацювати з командою розробників для того, щоб виконати графік випуску, особливо в останній тиждень або близько того до запланованого судна дата (тобто тестування / постановка користувача).

Вищезазначене - це твердження, які для мене справджуються на основі досвіду, але, схоже, зараз я маю на меті довести це - тому я прошу тут щось трохи поміркованіше, якщо таке існує.

Чи може кожен, кому довелося «продати» ідею фіксованого (або, можливо, напівскладного) циклу випуску керівництву, дати деякі вказівки щодо того, які аргументи / стратегії ефективні чи переконливі, а що ні? Окрім очевидних суперечок щодо розкладу та завислих витрат, чи є якісь важкі дані / докази, які були б корисними для того, щоб зробити випадок, що доставка вантажів насправді важлива, навіть у «корпоративних» умовах?

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

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

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

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

Більше того, цінність нещодавно розробленого програмного забезпечення, що сидить на полиці, схожа на цінність ящика сиру, що сидить у холодильнику ресторану: воно повільно гниє. Його вартість зменшується, оскільки ваші конкуренти наздоганяють. Він також відмовляється, оскільки стає складніше і ризиковіше ставити нове програмне забезпечення на обслуговування, оскільки його розробники переходять до інших речей. Через пару років на полиці це може бути насправді нікчемним. У такому випадку ваша компанія вирішила відмовитися від капіталу, який інвестувала в його розвиток. Цілком можливо, що власники компанії - акціонери - будуть незадоволені з цього приводу.

Є одне, що ви, як розробник, повинні з'ясувати. Чи готове ваше програмне забезпечення до впровадження наприкінці циклу випуску, який ви пропонуєте? Чи готовий до роботи, чи є ще чимало ще роботи та грошей, які потрібно витратити, коли ваша компанія приводить її у виробництво? Ваша компанія володіє ліцензіями на сервери та програмне забезпечення, необхідними для розгортання програмного забезпечення? Чи включає ваш робочий продукт план розгортання? Пройшли навчання кінцевих користувачів? Чи були перетворені виробничі дані? Якщо ваше нове програмне забезпечення передбачає зміну способу ведення вашої компанії, чи готова компанія внести ці зміни? Ви розробили схему паралельного запуску речей, щоб переконатися, що нові речі працюють так само добре, як і старі речі?

Усі ці випуски можуть легко зменшити витрати на розробку програмного забезпечення. Розумна команда з управління проектами робить все можливе, щоб спланувати, скласти бюджет та запланувати все це. Ви зробили цю роботу? Ви дали зрозуміти керівництву? Якщо ні, то, можливо, вони розумні йти повільно на ваші розіграші.

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

Можливо також, що ваша команда управління не функціонує. Чи розробила ваша команда щось, чого не хоче інша компанія? Чи загрожують ваші нові речі загрозою виходу з вашої торгової чи виробничої команди? Якщо так, то деякі керівники можуть торпедувати це, кажучи, що це занадто ризиковано. З цим нічого не можна зробити, якщо ви не генеральний директор.

Ви попросили вагомих аргументів для своєчасного розробки програмного забезпечення. Є один дійсно переконливий аргумент: рентабельність інвестицій. Компанія вирішила інвестувати в це програмне забезпечення, і тепер вони вирішують витратити інвестиції, оскільки ваше програмне забезпечення повільно гниє на полиці.

Вторинним аргументом для своєчасного розгортання є мораль вашої команди. Поспішайте і чекайте - це не гарний спосіб мотивувати творчих розробників робити добру роботу. Ви можете втратити свою команду, якщо вони не отримають задоволення від того, як їхня робота переходить на службу.

Спочатку подивіться це відео:

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

Резюме:

Спосіб доставки вчасно і в бюджеті такий: коли у вас не вистачає часу або не вистачає грошей, ви доставляєте. Це воно.

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

Те, як ви виліковуєте молоть, - змушуючи людей робити це на початку циклу розробки продукту , а не в кінці.

Внесення змін до товарів за тижні до дати випуску є дуже руйнівним з очевидних причин. Це правда, чи є зміна новою функцією, зміною процесу розробки програмного забезпечення або спробою виправити давню помилку, яка відсутня в графіку розробки.

Коли хтось приходить до мене за виправленням чи зміною пізно в циклі розвитку, я завжди запитую їх у цьому: "Що ви хочете, щоб я не закінчився, щоб я міг зробити вашу справу?"

Якщо вам потрібен мотиватор грошей, це саме так: дослідження доводять, що чим пізніше ви зачекаєте в життєвому циклі програмного забезпечення, щоб реалізувати функцію або виправити, тим вона дорожча. Експоненціально. Це не важко довести.

Ви чітко описали проблеми, з якими ви стикаєтесь, однак мені незрозуміло, чому менеджери поводяться таким чином. Ви можете уточнити? Наприклад, ви вважаєте, що він готовий до розгортання, чи хтось не погоджується, якщо так, хто і чому? Чи є колишніми працівниками бюрократів

Це дуже схоже на проблему зрівняння можливостей проти бажання, у вас є бажання звільнити, але не здатність (авторитет), ті, хто має повноваження, не мають бажання.

Вам потрібно з’ясувати, чому їм не вистачає бажання - це маркетингова причина (тримайте його ще рік, поки ми доїмо стару версію ще трохи), чи це страх / впевненість (Якщо у неї є помилки, це змусить нас виглядати погано , коштуйте нам грошей ...., не вистачає ресурсу (не можу дозволити собі витрати на доставку / упаковку / PR-речі), це комерційно, коли ваші деякі незрозумілі тонують до поганого надлишку прибутку, і вони не хочуть, щоб ви заробляли гроші ( Не так нерозумно, як це звучить).

Я також підозрюю, що існує повага між зацікавленими сторонами, тому розумні дискусії для дорослих не виникають.

Вибачте - не конкретна відповідь, яку ви просили, сподіваємось, про пару речей подумати.

Перше, що слід врахувати, це переконатися, що ваші випуски не мають високого ризику .

В ідеалі, у ваших запитах на зміни повинен бути розділ, який називається " Пом'якшення ризику" , який містить інструкції про відкат до попередньої версії, якщо все піде не так. Небезпечне попереднє тестування не може замінити простий варіант повернення змін.

• ^{У схильних до ризику середовищі, я не можу уявити собі спосіб зробити незворотні зміни безболісним.
  Якщо багато / більшість ваших випусків потрапляють до цієї категорії, ви можете переглянути свою архітектуру.}

Ризик не відпускаючи повинен бути викрито, якщо ви хочете DEV графік команди , які будуть ставитися серйозно.

Якщо у ваших випусках виправляються проблеми з виробництвом / підтримкою та відключеннями, це зробити досить просто, перерахувавши їх і вказавши, що виробництво ризикує повторити їх, якщо його не оновити.

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

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

Описаний вище спосіб по суті робить тісніший і явніший зв’язок між оновленнями вашої програми та проблемами виробництва.

Через це, ви можете очікувати більшої участі в ескалації виробничих питань . Ви можете використовувати їх як можливість для просування свого бачення суворіших запланованих оновлень. Ви навіть можете самі запустити деякі ескалації, щоб прискорити процес прийняття бажаного підходу.

• ^{"... рекомендую розглянути можливість оновлення програми до новішої версії ( XXабо пізнішої версії). Ця, яка зараз розгорнута у ваше середовище ( XX-2), сильно застаріла - два основні випуски за поточною базою коду. Як результат, деталі для таких простих збоїв є глибоко захований у журналах та нерозбірливому смітті повідомляється додатком до клієнтів замість чітких описів відмов - викликає користувачів та підтримку витрачати час на розслідування справ, які насправді досить прості "
   
  Вище - коментар, який я додавав деякий час тому в програмі підтримки трекера для квитка пов'язані з конкретним виробничим інцидентом. Незабаром після цього "зацікавлені сторони" зв’язалися із командою розробників, запитуючи, як слідкувати за нашими випусками та як вони можуть допомогти в розгортанні їхнього оточення. Ох, і вони також швидко модернізувалися зXX-2версія теж. :)}

Коли ескалація виробництва відбудеться, вам краще бути готовим швидко та чітко представити своє бачення.

Одне, що вам стане в нагоді, - це вибрати та відстежити, хто несе відповідальність за пробуксування релізу. В основному, вам потрібно вміти швидко і чітко відповідати на запитання типу "хто несе відповідальність за те, що запланований реліз не відбувся?" Якщо ви не готові, вони можуть вибрати шлях найменшого опору і покласти на вас провину. Як зазначалося в коментарях до іншої відповіді , "Ви можете потрапити в гарячу воду, від якої ваше керівництво намагається захистити вас".

Останнє, але не найменше,

це займе час

(ви, мабуть, це вже знаєте, але, схоже, варто це чітко зазначити)

Те, що ви шукаєте, можна охарактеризувати як зміну ставлення, від «ризиковано звільнитись » до «ризикувати НЕ звільняти ». Зміни ставлення рідко трапляються протягом ночі, можливо, потрібне терпіння, щоб завершити зміну.

Над вашим запитанням висить великий знак запитання, і саме тому ваша компанія не бажає випускати програмне забезпечення. Це не завжди є простим випадком відмови від ризику. Часто є інші причини, які часто не передаються з високих управлінських висот. Тож моє запитання до вас: "Ви сіли зі своїм начальником і запитали його, чому випуск продукту тримається?".

Існує велика різниця між управлінням ризиком та його уникненням. Можуть бути юридичні чи маркетингові причини затримки випуску товару. Це можуть бути питання довіри між керівництвом та командою розвитку. Товар може не відповідати потребам замовника, навіть якщо це саме те, про що клієнт просив місяці тому. Це може бути навіть справа, коли хтось із менеджменту серйозно прикриває дупу, намагаючись перекласти провину за затримку в інше місце, або навіть затримку з боку третьої сторони, яка вимагає, щоб щось завершити до того, як ваш продукт поставиться. Я міг би придумати десятки сценаріїв. Досить часто розробник бере на себе відмову від ризику, не розуміючи іншої сторони рівняння, яка не стала очевидною. З іншого боку, це може бути просто поступливість, конфлікт між особами в компанії,

У всіх випадках важливо мати більше інформації про причини затримок випуску продукту та використовувати цю інформацію для побудови справи про випуск продукту якнайшвидше. Так, це може бути дуже неприємно, але є й інші способи вирішити ці ситуації, не ризикуючи ні конфронтацією з вашими начальниками, ні вигоранням. У подібних ситуаціях я сам збирав інформацію, задокументував будь-який прогрес, який я досяг, а потім, якщо ще гірше погіршився, просто відклав проект і перейшов на щось інше. Там, де мені вдалося повернути проект на шлях до виходу, зазвичай це було результатом обгрунтованої ділової справи, заснованої на інформації, яку я отримав як відгук на поставлені питання. Там, де я не зміг переконати керівництво, що товар слід відвантажувати, Я задокументував небажання відвантажувати це як просто закінчений проект і чекаю затвердження керівництвом звільнення. Тоді я переконуюсь, що мій менеджер підписує мій документ як прийнятий та зрозумілий керівництвом, щоб мій власний недокурок був прикритий, якщо вони намагатимуться пізніше звинуватити мене у невідпущенні.

Вам завжди потрібно розставити крапки і перекреслити Т, щоб уникнути запізнення доставки пізніше на вас (як би не було несправедливо), а також важливо уникати занадто емоційного зв’язку з подібними питаннями, якщо вам не подобається ідея про добре зароблену виразку. Дивлячись на власну ситуацію з певним професійним загоном, ви можете знайти рішення, яке представляє себе, тому що ви ефективно розмістили себе на більшій "відстані" як би від проблеми. Якщо ви не можете скласти свою справу, можливо, вам доведеться на деякий час пропустити її, але для того, щоб зробити вашу справу в першу чергу, вам потрібно здатися професійно відірваним і мати аргументи на основі інформації, яка тісно пов'язана з Ваша компанія та її внутрішня робота.

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

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

але в реальному світі фактичний реліз - це чиясь проблема, ви повинні доставити його їм, а потім трактувати це як випуск. Як тільки він вийшов із ваших дверей, його доставлять. Якщо вони просто сидять на ньому, це не ваша проблема (насправді, це чудово, про нього не повідомляють про помилки! W00t! Бонуси за випуск без помилок у всьому світі;))

Тож у будь-якому випадку вам потрібна система управління змінами та менеджер випусків. Тоді це все просто (за винятком того, що вам потрібно керувати контролем змін, тому управління джерелами плюс розгортання дуже потрібні. Це вимагає організації, але якщо ви організовані, це легко).

Я не уявляю, що поставити команду Dev, відповідальну за бізнес так, як ви описуєте, - це "гарна річ", це може замаскувати справжню проблему, але, якщо команда Dev не буде в правильному становищі, щоб зважити вкладення продажів, маркетингу тощо. тощо. Ви ризикуєте звільнитись з помилкових (і потенційно поганих) причин.

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

Ти намагався:

1. Попросіть керівництво для замовника або набору клієнтів, які виступають зацікавленими сторонами під час розвитку? Зазвичай ви можете знайти одного замовника, який може взяти проміжні випуски та дати відгуки. Вони можуть бути чудовими захисниками, коли настав час звільнитись. Навіть "обмеженого випуску" одному клієнту може бути достатньо, щоб допомогти керувати потоком
2. Побудова плану випуску, включаючи точкові випуски. Тобто ви можете випустити 3.4 вже сьогодні, оскільки реліз 3.4.1 запланований на сьогодні + 1 місяць. Це разом з хорошою ідеєю, про яку ви вже згадували, що каденція випуску допомагає цьому повідомленню.
3. Отримайте підтримку, продаж чи маркетинг на вашому боці. Створіть виправлення, які вирішували б найкращі 3 запити на підтримку, і ви можете отримати союзника з іншого відділу. Якщо ви не можете знайти зацікавленого клієнта, як у №1, спробуйте це з кількома продажами. Пропонуйте бути доступними для торгових зустрічей та принести товар. Коли ви їдете в дорогу, покажіть продавцю, який ви знаходитесь з продуктом (у якому б стані він не знаходився), попросіть їх потягнути за вас.

Щоб відповісти на ваше інше питання про те, "чому керівництво буде випускати реліз?" Компанії роблять це постійно у сферах, що не стосуються ПЗ, і я не думаю, що це безпрецедентно. Наприклад, у вас є новий реліз, який готовий до запуску, все перевірено і зроблено. Але стара версія ще не витіснила конкуренцію. Після того, як конкуренція випускає конкуруючий продукт, ви стару версію, керівництво випускає версію, що чекає на полиці, і порушує ринок, стримує конкуренцію і підтримує продажі та репутацію лідера ринку. Випускаючи занадто скоро, підкажіть своїм конкурентам, які, можливо, краще уявлять вашу дорожню карту і намагаються перемогти вас до кінця гри.

При всьому сказаному ... Бритва Ханлона, мабуть, правильна відповідь :-)

Ідіть геть від цієї компанії, вони не розуміють програмного забезпечення. Але якщо серйозно, то програмне забезпечення - це те, що змушує працювати систему, уявіть, якби ви робили машини, чи заводи автомобілів повільні? вони чекають на випуски автомобілів? Вони є поступовими та бюрократичними? Ні, вони намагаються робити речі найшвидшим і чистішим способом. У вас є проблема управління, і ви повинні працювати над цим як конфлікт з управлінням, спробуйте висловити їх у своїх умовах. Запитайте, що означає для них ризик, а потім спробуйте мінімізувати його. Почуття ваших дияволів також важливі, оскільки вони повинні справлятися з рішеннями, які будуть прийняті вашим втручанням. Чи будуть вони щасливі, щоб усі молодші прибули вчасно? Якими були б призи / штрафи? І т. Д. Зараз я дам вам практичний підхід до цієї проблеми, трохи екстремально, але попросіть аудит.