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

Всім привіт! Мене звати Андрій Троянов, я Delivery Manager у компанії Innovecs. У цій статті я поділюсь набутим досвідом роботи із технічним боргом, підходами до його швидкого повернення, мінімізації на попередніх та поточних проєктах.

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

Що таке технічний борг і чому він виникає?

Технічний борг виникає, коли команда розробки змушена прискорити процес постачання продукту чи оновлення, відкладаючи рефакторинг на майбутнє (зазвичай невідоме). Згідно з теорією Стіва МакКоннелла (Steve McConnell) — відомого автора книжок «Завершений код», «Швидка розробка» тощо — зазвичай існує дві глобальні причини виникнення технічного боргу.

  1. Навмисний технічний борг. У гонитві за зменшенням time-to-market та цілями бізнесу по колонізації ринку команди розробляють продукт у шалених темпах, відкладаючи базові інженерні покращення на потім та фокусуючись виключно на швидкості постачання (release to web/production). При цьому команди жертвують якістю: вартість забезпечення якості суттєво зростає під час внутрішніх та зовнішніх доробок, ніж на початку циклу, коли вона включена в процес розробки та на неї виокремлюється час, зусилля та кошти.
  2. Ненавмисний технічний борг. Трапляється, що код вимагає покращення через певний проміжок часу, а команди дізнаються про це із власного гіркого досвіду — коли продукт після виходу в світ отримує негативний зворотний відгук від користувачів. У результаті RCA (аналізу першопричин) команди виявляють, що або залежності у модулях були погано прорефакторені, або сам код продукту застарів і потребує масштабного оновлення.

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

Які бувають технічні борги?

Мартін Фаулер (Martin Fowler) — один із авторів Manifesto for Agile Software Development — допрацював теорію згаданого вище Стіва МакКоннелла, додавши до дихотомії «навмисний/ненавмисний» ще одну ознаку. Вона розподілена за принципом «розсудливий/необачний» у контексті визначення технічного боргу. Відповідно вимальовується матриця із 4 квадрантів, що відображають види технічного боргу:

  • Необачний/навмисний.
  • Необачний/ненавмисний.
  • Розсудливий/навмисний.
  • Розсудливий/ненавмисний.

Як ми вже з’ясували, різниця між навмисним та ненавмисним боргом полягає у зворотному підході до роботи та ступені обачності команди, коли база коду потребує відлагодження. Різниця між розсудливим та необачним базується на:

  • повному усвідомленні командами факту накопичення боргу: «Ми знаємо, що ми пожертвували рефакторингом у цій ітерації/задачі/фічі та маємо його виплатити якомога швидше»;
  • неусвідомленні: «Ми накопичили борг? Ми не рефакторили код достатньо? А у нас в DoD (definition of done) закладений рефакторинг взагалі?».

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

У будь-якому разі кожна команда зіштовхнеться із наявністю певного технічного боргу у продукті. Нерентабельно займатися виключно інженерією в ім’я надлишкової якості продукту, не даючи цінності ні бізнесу, ні користувачам. Головна різниця виявиться в обсязі технічного боргу. Одні будуть потрапляти в узгоджений відсоток, визначений в метриках якості. Інші будуть вимушені займатись дуже частим «прибиранням» — доопрацюванням та погашенням накопиченого відсотка до загальноприйнятих стандартів якості.

Підходи до управління технічним боргом

Стратегії роботи із технічним боргом залежать від обраного процесу управління проєктом та умовами контракту між замовником і виконавцем у аутсорсингу. У гнучких фреймворках і методологіях, зокрема у Скрам, управління технічним боргом відбувається прозоро із залученням достатньої кількості зацікавлених осіб із різним ступенем відповідальності за робочий продукт. До команди розробки залучаються й інші зацікавленні особи залежно від організаційної структури — наприклад, спонсор проєкту, власник бізнесу, тощо. На моїх попередніх проєктах, де я використовував Scrum/SAFe, були задіяні наступні підходи до управлінням боргом:

  1. Пріоритезувати технічний борг прозоро на зустрічах з «причісування беклогу» (Refinement or Grooming) із власником продукту, брати в роботу в кожну ітерацію (відсоток варіювався у розмірі 10-20% в залежності від мети ітерації або її наближення до релізу).
  2. Закладати рефакторинг окремим пунктом в DoD (критерії готовності продукту, погодження його продукту та командою розробки). Часто регулювати DoD — в основному ми переглядали та корегували раз у 2-3 місяці перед новим (program increment).
  3. Відслідковувати відсоток технічного боргу у беклогу продукту у порівнянні із задачами та ризиками; стандартизувати розподіл кількості таких задач у пропорції із ризиками за ітераціями.
  4. У кожен program increment (PI) брати архітектурні та інфраструктурні енейблери в достатній кількості, забезпечуючи стабільність продукту.
  5. Постійно пояснювати ризики, пов’язані із недостатнім плануванням, роботою над нефункціональними вимогами рішення у грошовому еквіваленті до початку та під час розробки проєкту (коли власник продукту подає попередні total cost of ownership на розгляд спонсору проєкту).
  6. Застосовувати метрики відслідковування накопичення технічного боргу та регулярно переглядати їх щодня, перед ревізією беклога та протягом ретроспективи. Наприклад: кількість виявлених дефектів на N рядків коду, глибина наслідування, цілісність коду, колективне володіння базою коду (collective code ownership) тощо.
  7. Закладати рефакторинг в оцінку (абсолютну чи відносну) під час кожного планування (release planning, PI planning, iteration planning, replenishment — у разі можливості).
  8. Збирати та ділитись набутими знаннями та практиками управління технічним боргом мінімум раз у IP (Innovation and Planning). Зазвичай це кожна п’ята ітерація інновацій та планування у SAFe.

Якщо існують певні контрактні зобов’язання, або проєкт постачається за більш жорсткими методологіями, я запропонував би наступні дії:

  • Прописувати рефакторинг у RFP (request for proposal) у відповідь на запит замовника у SoW (statement of work).
  • Детально описувати нефункціональні вимоги у документах за вимогами.
  • Стандартизувати процедури у плані управління якістю проєкту/продукту.
  • Визначити допустиму похибку технічного боргу у метриках якості.
  • Закладати рефакторинг у прорахунок вартості якості продукту (cost of quality).
  • Підтримувати актуальність технічної документації.

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

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

На іншому проєкті ми одразу домовились, що кожен восьмий день спринта ми виокремлювали на рефакторинг коду, в той час як тестувальники тестили сценарії регресії білда для тестування прийомки оновлень продукту користувачами (UAT). Ще два дні залишалися для виправлення дефектів і підготовки до рев’ю спринта. Ми це погодили на рівні CTO/CDO (Chief Delivery Officer). І цей підхід був відображений у негласних згодах команд.

Як технічний борг впливає на розвиток проєктів, і які наслідки його ігнорування?

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

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

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

Коли борг стає деструктивним елементом системи, він розкладає її зсередини, призводячи до неминучої ентропії. Проблеми накопичуються, як снігова лавина, а несвоєчасне виправлення може зовсім не допомогти.

Цього всього можна уникнути, якщо налагодити своєчасний план комунікацій та управління технічним боргом, особливо у контексті практик гнучких постачань продукту — старий, добрий Agile. І дійсно — майже всі фреймворки, такі як Scrum, SAFe, RAD, XP, FDD, DSDM, частково Kanban та Lean та їх гібриди — ScrumBan, Scrum+XP, тощо — за своєю суттю спрямовані на:

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

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

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

Висновки

Нижче підсумую ключові рекомендації з управління технічним боргом:

  • Визначайте стратегію управління технічним боргом заздалегідь.
  • Погодьте цю стратегію із ключовими учасниками проєкту.
  • Відкрито адресуйте питання наявності технічного боргу на загальних зустрічах (ревʼю-ітерації, ретроспектива, планування ітерації, планування PI), або через проксі (скрам-майстер, власник продукту) тощо.
  • Пріорітезуйте борг-задачі разом із «фічами» та ризиками в процесі «причісування» беклогу продукту.
  • Закладайте рефакторинг в оцінки виконання задач, сторіз, оновлень.
  • Проговорюйте практики роботи із технічним боргом на ретроспективі та беріть визначенні дії (action items) в кожну наступну ітерацію.
  • Постійно відслідковуйте тренди метрик якості, щоб своєчасно визначити та зменшити вплив боргу на продукт.
  • Зробіть свій DoD для всіх учасників проєкту прозорим (wiki-сторінка або фізична роздруківка на дошці команди) та регулярно оновлюйте його.

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

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Чьотка стаття, взяв на замітку.

Дякую за Ваш відгук — радий, що Вам сподобалась стаття!

Все просто, технический долг образовывается тогда, когда тех обьектом управляют например, юристы. Несомненно, успешные професионалы своего дела, по привычке от точной техники хотят такой же отдачи как и от людей. (120% хотябы...) И обьяснять безполезно. Все должно укладываться в их план, мнение, мировозрение...
И например на запрос инженера(допустим что обоснованный) найдутся как отказать. А если будет буксовать, загонят в комплекс неполноценности(ака самозванца). Это на самом деле, плевое дело. У инженера конкретная компетенция связанная с железом или софтом. По этому на поле «психологического давления(или продавливания)» он проиграет тому, кто аналогичное количество лет, с утра до вечера практикуется в крючкотворстве, манипуляциях и проч. Отсюда и выгорание и техдолги. И откровенные мрази «делающие только то что нужно бизнесу» и зарабатывающие на том, на что забили, а нормальный инженер не стал бы.

Для части инженеров да, выгорание, а часть инженеров трансформируется в Макарычей. Из истории:

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

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

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

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

Так — класика першого варіанту. Добре що є позитивний тренд — тех борг зменшується. Підкажіть — що робили для того, щоб зменшити тех борг на проекті та чи складно було домовитись із клієнтом стосовно повернення боргу?

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

Дуже дякую за Ваш відгук, Романе — радий, що Вам сподобалась стаття!

Дельные советы в статье, благодарю.

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

Например, в юзер стори, которая расширяет функциональность определённого модуля, можно добавить рефакторинг.

это зло с какого конца ни зайди зло и технически это зло и управленчески это зло

Дякую за Ваш відгук!

Один из рабочих вариантов, который также рекомендуют, — закладывать ликвидацию части тех долга в нужные бизнесу фичи.

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

Например, в юзер стори, которая расширяет функциональность определённого модуля, можно добавить рефакторинг.

Я б радше радив одразу погодити та додати рефакторинг кожної одиниці беклогу (у межах розумного) як самобутній пункт у критеріях готовності продукту на початку розробки обов’язково проінформувати власника продукту або бізнесу про DoD команди ніж зіштовхуватись із ними в процесі роботи.

О прозрачности и открытости — согласен, обман и сокрытие пользы не дадут.

Я б радше радив одразу погодити та додати рефакторинг кожної одиниці беклогу (у межах розумного) як самобутній пункт у критеріях готовності продукту на початку розробки обов’язково проінформувати власника продукту або бізнесу про DoD команди ніж зіштовхуватись із ними в процесі роботи.

В идеальном мире оно так, вы и сами об этом в статье пишите.
При этом бывают кейсы, когда приходим на проект, строим лучшие практики, новый технически долг не создаём (по крайней мере, умышленный). Но технический долг уже есть к тому моменту. Клиент может быть категорически против инвестировать в его ликвидацию, ему нужны бизнеч фичи. Тогда и имеет смысл ему сказать, что для добавления новой функциональности в компоненте А или компоненте Б, нам нужно учесть технический долг, который должен быть закрыт совместно с этим.
Впрочем, я не настаиваю. Всегда есть альтернативные варианты.

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

Настоящие девелоперы (не вайтишники) и так прекрасно знают что такое технический долг.
Было бы очень ценно рассказать про технический долг не-техническим клиентам! Что бы они понимали как их обманывают ИТ-«галеры». Клиент не хочет разбираться что «внутри» — ему давай красивую игрушку, побыстрее и дешевле. И галера ему с радостью слепит такой «одноразовый» продукт. Вот только через несколько месяцев после релиза, когда пойдет рабочая нагрузка — окажется что все это шито гнилыми нитками и буквально разлазится на глазах. И починить тут уже ничего нельзя — можно только лепить заплатки.
Можно понять, когда клиент погнался за дешевизной — тут уж «сам дурак» и «а чего ты хотел за такие деньги». Но иногда-ведь ИТ галеры сознательно обманывают клиента что бы выиграть тендер! Обещают сделать быстрее других, обещают команду синьоров, а в итоге отдают все это лепить команде джунов. Галера экономит на техническом долге — потому что этот долг потом выплачивать не ей!
А вот если бы клиенты знали о техническом долге — то они указывали бы его в договорах! И после релиза заказали бы независимый аудит, который бы доказал неприемлимое качество кода и наличие технического долга. После этого — галере пришлось бы все переписывать по-правильному, но уже за свой счет. Пару таких прецидентов — и оставшиеся на плаву галеры научились бы работать на совесть!

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

не совсем так потому что тут ты путаешь откуда вообще берётся «технический долг» и то что ты описываешь это не совсем чтобы именно то

Основная проблема как это указать в договоре? Что является плохим кодом, как его формально юридически описать. Нет есть вполне измеримые величины, типа скорости отклика системы при нагрузочном тестировании в XXX пользователей на оборудовании такового вот типа, при количестве записей в базе Y — это можно измерить. А как измерить кривую архитектуру? Ну и аудит стоит денег, его менеджеру нужно еще обосновать перед своим начальством.

А как измерить кривую архитектуру?

Легко — отдать на аудит специалистам.

Аудит стоит денег, его менеджеру нужно еще обосновать перед своим начальством.

Если аудит покажет низкое качество — то платить за переделку будет подрядчик. На самом деле очень хороший аргумент — странно экономить на том, что бы проверить что ты не купил халтуру.
Когда-то давно, когда у нас на проекте еще был правильный менеджер — мы то же делали аудит чужого кода. Клиент хотел что бы мы использовали какое-то говно, которое ему хотели впарить индусы — мол это не с нуля писать, а уже все почти готовое, чудо фреймвок — только немного допилить.
Менеджер написал клиенту: наша компания работает по определенным стандартам качества — поэтому мы сначала сделаем аудит чужого кода. Ну и в результате легко доказали что и архитектура и код — не соответствуют стандартам нашей компании. А значит что? Или мы берем и рефакторим этот код до нужного качества (а клиент за это платит) — или клиент идет к индусам и они ему доделают как он хочет, но мы это поддерживать уже не будем. Учитывая, что у клиента уже успешно работала система, которую мы ему делали то он благоразумно решил что лучше все-таки позволить нам дальше расширять ее, а не связываться с чужим говнокодом.
Но это было в давние времена, когда ***к-хуяк и в продакшин еще не стало мэинстримом.

Кратко: хорошо делать хорошо, плохо делать плохо, и давайте прикрутим KPI ©

Технический долг еще может быть и, как бы так сказать, «внезапный» и возникать на ровном месте. Типа обновились базы vulnerabilities, и security scan начал требовать апгрейда пачки библиотек.

На іншому проєкті ми одразу домовились, що кожен восьмий день спринта ми виокремлювали на рефакторинг коду, в той час як тестувальники тестили сценарії регресії білда для тестування прийомки оновлень продукту користувачами (UAT). Ще два дні залишалися для виправлення дефектів і підготовки до рев’ю спринта. Ми це погодили на рівні CTO/CDO (Chief Delivery Officer). І цей підхід був відображений у негласних згодах команд.

Хорошее решение.
У меня на одном из проектов были выделены т.н. «стабилизационные спринты» половинной длины — когда релиз состоял из 3-4 двухнедельных спринтов плюс последний спринт в 1 неделю для работы с долгом, мелкими багами и документацией, и работа над фичами в этом спринте не велась. Очень позитивные воспоминания остались

Ничего «внезапного» на самом деле в этом нет, а очень даже предсказуемые риски. И нужно не только знать, как на них надо реагировать в теории, а ещё и иметь по науке настроенную и предсказуемую систему мотивации.

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

Технический долг еще может быть и, как бы так сказать, «внезапный» и возникать на ровном месте. Типа обновились базы vulnerabilities, и security scan начал требовать апгрейда пачки библиотек.

конечно а у нас нет и не предусмотрено ни плана ни тем более проверенной практики обновления версий либ кто бы б мог вообще подумать что они могут меняться доколе ))

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

Технічний борг — це лише не дуже кошерна назва для вельми правильної та корисної субстанції. Бо він не є боргом взагалі, лише канбанами структури TODO → PROFIT!!!

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

Управління потребує звичайного, без шуму та пилу. Досить бажаною є візуалізація, із дробленням на візуалізації більш низького рівня. Що важливо розуміти: система з канбанами не має вбудованого механізму генерації KPI показників, цей фукнціонал (оцінку складності та ресурсоємності) треба впроваджувати як додаткову фічу. Без того — ризикуєте поховати пріоритетні завдання через їхню геморойність та низьку оплату за них (а те й від′ємну, з овертаймами).

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

Олексію, дякую що поділились своєю точкою зору. Як і будь-який фреймоврк управління процессом — Kanban має свої переваги та недоліки. Серед купи переваг, головний його недолік у тому, що команди мають бути дуже «зрілими» у технічному і процесному плані аби управляти свої роботою самостійно. Другорядний — Kanban, все ж (виключно у моєму досвіді), більше орієнтований на сервіс ніж розробку нових фічей.

Що важливо розуміти: система з канбанами не має вбудованого механізму генерації KPI показників, цей фукнціонал (оцінку складності та ресурсоємності) треба впроваджувати як додаткову фічу.

Зазвичай — спонсору проекту/клієнту/керівництву організації цікаво коли і за скільки буде зроблений проект. Хоча б верхнерівнево. Там є купа цікавих метрик (Lead Time, Cycle Time, Response Time, Delivery Rate і т.д.) і є SLA — проте, все ж таки, застосовуючи Kanban складно прогнозувати поставку фічей. Це більше про управління робочим потоком.

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

Для цього потрібно щоб у системі були чітко визначенні класи сервісів, сформовані SLA (service level ageements) які відповідають SLE (service level expectations), SRM (Service Request Manager=PO) та SDM (Service Delivery Manager) мали чіткі домовленості по розподілу різних типів задач на пріоритезацію, активності Ustream (стадії до розробки) та Downstream (весь цикл розробки та тестування) були прозорими і зрозумілими для всіх учасників, а бізнес слідував чіткому правилу не міняти нічого у пріоритетах після того, як задачі пішли у стадію аналізу. Для цього потрібна «зрілість» усіх учасників та чіткі політки роботи (короткі письмові домовленості по процесу та результату).

Канбан — це не фреймворк. Це примітив. І побудування системи через примітив. Тобто, канбан є маленьким об′єктом, в якого описаний життєвий цикл — а від так він може бути вбудований в інші системи, в тому числі експортований за межі організації через проксі-об′єкт. І навіть на зовнішнє управління.

Тому сам канбан нічого не прогнозує — це лише система менеджменту окремої справи, замкнена в ній самій. Саме тому технічним боргом найкраще керувати через канбани: його деталі заховані в канбані, деякі з яких легко доступні для зовнішнього керування, деякі — лише на читання, деякі приватні (тільки для його виконавців). І через спрощення до канбанів борг можна не тільки передавати на виконання, не тільки проштовхувати, щоб скоріше, а навпаки, заморожувати у багатьох легко керованих станах, призупиняти, породжувати залежні канбани чи навпаки, ставити у залежність до якого-сь канбану чи іншого постачальника сигналів. Але канбан не можна підписати на щось, це не функціонально одиниця — тобто він зрушить з місця ЛИШЕ якщо на це буде воля керівника чи це буде запланованим пунктом плану, що зараз виконується.

А від так — канбан не передбачає строки. Але МОЖНА передбачати лише як інформативне поле, МОЖНА передбачити контакти та протоколи, за якими можна дізнатися стан виконання — але правила забороняють робити це в інший спосіб. Звісно, якщо обставини змінилися, правила можна і порушити (по якій саме процедурі — канбан зазвичай не передбачає).

Інакше кажучи, впровадження канбану для керування технічним боргом НЕ ВИМАГАЄ створювати керування за канбанами для процесів його виконання. Канбан — повністю віртуальний об′єкт, декларативний. На саме виконання адміністративних процедур у канбані передбачено 0 ресурсів. Звісно, це можна змінити, призначивши принцип визначення, але зазвичай то погана ідея, бо визначити достовірно досить важно, можна лише встановити примусово.

Що дає по ітогу використання канбанів? Waterfall, звісно ж, як би ви не намагалися зробити вигляд, що його нема. Але паралелізований waterfall. І саме система вотерфолу дає найкраще передбачення і строків, і виділення ресурсів, і роздачу приоритетів потокам та квантів часу.

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

Недоліки канбанів: Дурням здається, що оскільки канбан простий ззовні, то він простий і зсередини. Тому не дуже кваліфікований менеджмент вимагатиме, наприклад, щоб знизили всі строки виконання на 15%, під угрозою зриву проекту. Тому, майте напоготові червоний канбан із надписом СТРАЙК, та тупо погрожуйте додати його в потік виконання. Одного разу достатньо, щоб власник процесу впевнився — процес на 100% керований та врівноважений, тобто, його канбану можна довіряти. Особливо, коли страйк точно так само припиниться за хвилину, щойно його канбан отримає сигнал «призупинити». А чому тоді не можна змінити строки? Бо це строки передбачення, read only, вони почнуть мінятися при кожному зміні планів, пріоритетів, у процесі виконання.

Я погоджуюсь із Вами, що канбан геть не простий у застосуванні як може здатися при першому погляді некваліфікованих фахівців перед застосуванням. І я погоджуюсь, що канбан метод починається із створення елементарної системи управління робочим потоком задач. Адже його головний принцип — «Start with what you do now» а перша практика — «Visualize the workflow». Далі — він поступово еволюціонує у виважену систему із відповідними принципами, практиками, заходами та ролям. Він адаптивний та гнучкий оскільки дозволяє організації змінювати та налаштовувати як завгодно щоб досягти виробничих/проектних цілей. Питання в тому, що не все організації/менеджери/консультанти/проекти готові до переваг використання метода.

Що дає по ітогу використання канбанів? Waterfall, звісно ж, як би ви не намагалися зробити вигляд, що його нема. Але паралелізований waterfall. І саме система вотерфолу дає найкраще передбачення і строків, і виділення ресурсів, і роздачу приоритетів потокам та квантів часу.

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

Недоліки канбанів: Дурням здається, що оскільки канбан простий ззовні, то він простий і зсередини. Тому не дуже кваліфікований менеджмент вимагатиме, наприклад, щоб знизили всі строки виконання на 15%, під угрозою зриву проекту. Тому, майте напоготові червоний канбан із надписом СТРАЙК, та тупо погрожуйте додати його в потік виконання.

У самому методі є вбудований механізм, який дозволяє системі постійно фокусуватись на саморегуляції потоку, ефективності використання ресурсів (фізичних та людських) а також на часі проходження всього циклу виробництва (lead time and cycle time) із меншою вартістю (delivery rate).
І він називається — ліміти роботи в прогресі (WIP limits). По-перше — вони дисциплінують учасників процесу завершувати почату роботу, зменшуючи ризики та витрати на розробку та поставку фічей. По-друге — практика дозволяє мінімізувати «втопленні витрати» (sunk costs). По-трете — вони дозволяють переміщувати системні обмеження забезпечуючи безперебійну роботу всієї системи, а не окремих елементів. По-четверте — ліміти зменшують ризики втрати контексту від постійних переключень.

Тех долг это плохо, есть все нужные подходы чтоб его избегать
Для этого надо достаточное количество ресурсов на проекте
Квалифицированные разработчики

Да именно так. Там не сложно

Это так. Мне кажется, что главные причины тех. долга, да и разных других проблем — это в основном:
— Нет времени (постоянная потогонка),
— Нет квалификации (никто просто не замечает проблем или не знает как их решать),
— Нет мотивации (частично проистекает из первых двух, overworked & underpaid, выгорание, хаос, или просто всем пофиг).

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

В jelled team(s) и при адекватном подходе к разработке этих проблем вообще не возникает и никому не нужно пихать никаких энейблеров никуда и что-то планировать. Есть всякие правила скаутов («Always leave the campground cleaner than you found it») и т.д. и т.п. и естественное понимание, когда и что менять.

Сокращу до смысла: если менеджмент — тупые совы, то какой стороной ни поверни, как ни назови — сложно из букв О,П,Ж,А собрать слово PROFIT.

Дякую за ваш коментар! SAFe не такий страшний як здається. Він розрахований на поставку програми (декілька зв’язаних між собою проектів) із кількістю учасників до 120 людей. Чим більша кількість залучених осіб — тим чіткіші та більш жорсткі мають бути процедури. Тому SAFe не такий гнучкий як Scrum, а тим паче ніж Kanban. Він має більше постулатів оскільки управління декількома «потягами» вимагає структурності. Common sense у такому випадку — привілей.

То есть много денег, много квалифицированных кадров, дохера времени — и всё ок будет? Так любой дурак может. А за мало времени, существующими кадрами, и с минимальным бюджетом — слабо? А те кто умеет управлять тех.долгом — могут.

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

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

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

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

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

Всех, кто в это время попытается систему дестабилизировать, использовать «внезапно» высвобожденные ресурсы, подсунуть в горячий процесс свои хотелки, использовать равновесие для инициации своих конфликтов — нужно немедленно и любой ценой из системы вышвырнуть, притом публично и жёстко, так чтобы другим не повадно было. Вот это — тёмная сторона, которая стоит за крупным техническим долгом: нужен несиметрично жёсткий ответ. Особенно в адрес паникёров, истеричек, прокачивальщиков ЧСВ, и... показушных оптимистов. Маньяки допустимы — но по ним руку держит на пульсе риск-менеджмент, в буквальном смысле заставляя доказывать необходимость каждого шага. (Их тоже демотивируют, но после демобилизации).

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

Если кратко: технический долг считается управляемым, если он делимый на задачи, свойственные системе. Менеджмент при этом спокойно попивает пуэр. Если технический долг системе не свойственный (либо управленцы прячут голову в песок и боятся об этом сказать) — делается мобилизация. То есть рокировка в системе: менеджмент из источника экспертной власти становится машиной жёсткого контроля, а власть переходит в риск-менеджмент. Если риск-менеджмент не существует хотя бы даже в количестве 1 человека, система к мобилизации не способна и её ждёт быстрое выгорание при попытке это сделать. Может банально повезти, так случалось. Но вот чтобы везло постоянно — увы.

Підписатись на коментарі