Un-FuckUp-able Development Protocol (UDP)

Нещодавно після чергового Team Building'a отримав від одного Колеги-Графомана лист-притчу про велику кнопку «зробити все добре». Він і раніше балувався винаходом велосипеда, але, в цей раз конструкція здалася мені дуже вдалою. Кому цікаво — прошу-запрошую під кат. З його дозволу дослівно:

В цю сієсту на веранді практично ніхто не курив, тому, що всі пішли на черговий дводенний SCRUM тренінг. Джонні стомлено окинув поглядом присутніх: Дему і Варю. Вони теж не були в захваті від того, що відбувається, було дуже жарко і задушливо, літо в Долині було в самому розпалі, і здавалося, що на вулиці навіть спекотніше ніж в Task Tracker'е.




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

— А хочете, хлопці, я Вам сказкочку розповім, про программистский Рай? — запитав Джонні, струшуючи попіл після чергової затяжки.

Варя і Дема понуро кивнули, але постаралися посміхнутися. Тоді Джонні дістав з кишені люльку, і, пояснивши, що це буде Long Run Story, став неквапливо занурюватися в клуби Balkan Delight (сорт тютюну).

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

Ініціалізація BIOS видала слухачам відомості про обладнання:


Ну і інший IO і периферія, типу «сторонніх» тестувальників, верстальників, дизайнерів, з якої всі були згодні. Так само погодилися, що дисплей це SCRUM дошка, а операційна система Linux, тобто рух Open Source конкретно і проривні інновації IT сфери зокрема.

Менеджмент, безумовно, віднесли до прикладного софту — Task Tracker'у і Cron. Електропостачання, зі зрозумілих причин, замінили на поняття Cash Flow від Замовників і Клієнтів. Адже комп'ютера не важливо звідки прийде енергія, важливо просто робити розрахунки, тому даність наявності енергії і джерело її виникнення теж ніким не оспорювався. Корпус, в їхньому випадку, звичайно ж був кастомный, з водяним охолодженням (басейн і сауна), разлоченным генератором тактової частоти (будь ніштяки, від кальяну і пива на веранді, куди не заборонялося брати ноутбук, до спортзалу в підвалі їхнього особняка). ДБЖ у вигляді угарнейших корпоративних вечірок і інших значних поблажок у presence time schedule так само, звичайно, позначився як невід'ємний і дуже потрібний девайс.

Пропустивши інші несуттєві моменти опису Джонні підбив підсумок:

— Отже, ми маємо 50+ людей, які вже пару років дихають тієї чи іншої методології розробки, але при цьому все одно у нас регулярно відбувається який-небудь FuckUp. Ми почали з самоорганізованої хаосу, тоді нас було 10. Потім нас стало 20, і 30, і 40, і у нас був «Водоспад» (модель розробки). І, коли все пішло не так, як ми звикли, ми стали робити SCRUM. І, начебто, все у нас чудово, стабільна ЗП, відмінний менеджмент, користувачі задоволені регулярно заносять копієчку, але все ж бачать проблеми? — підсумував Джонні.

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

Всі знали, що кожен з розробників регулярно отримує не тільки премії, але і «по шапці» за факапи. Що тестувальники «не тестують», а джуни не джунят. Верстальникам не вистачало "їжі", так як дизайнери були перевантажені микроменеджментом, то їх завалювало так, що вже розробники були змушені їх чекати. Про саппорт — цих бравих хлопців — могутніх вікінгів на чолі з самим Тором можна було з задоволенням писати лише панигирики та некрологи. А першою асоціацією менеджменту у всіх одноголосно був ранковий будильник, завжди дзвінкий не вчасно. Мабуть, не будемо продовжувати, Ви й самі все це знаєте, воно скрізь так, не тільки в IT.

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

Так само розуміли, що ні Скрам, ні Водоспад, і ніщо в цьому всесвіті не скасує здоровий глузд. Якщо відбувається пожежа на продакшені — його треба гасити. Якщо щось упустили і треба терміново щось буде переривання і випадання з контексту, це природно. Що не можна відмовитися від необґрунтованого спілкування з менеджментом, і ніякої SCRUM не врятує від раптово виниклої «диво-ідеї». Що технічний борг нікуди не дінеться, і завдань супроводу буде все більше і більше, до тих пір, поки кількість користувачів буде зростати. А саме забезпечення цього зростання і є ключове завдання, не менш важлива ніж розробка нових продуктових особливостей. І що ні скрам, ні канбан, ніщо не врятує від усього цього безладу, так як система не може бути замкнутою, вона дихає, вона — живий організм.

— Таким чином, ми всі хочемо рости, розвиватися, писати код, але, щоб все це було так само цікаво, як і зараз, нам потрібен якийсь новий «paradise»?

Всі кивнули. Джонні знову раскурил вже давно погаслу люльку.

«Ми володіємо командою, яку потрібно Ре-Инжинирить

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

— Всі ж пам'ятають різницю між TCP і UDP? — Джонні пояснив, що це метафорично в контексті казки, і всі погодилися, що UDP краще підходить для стрімінг, але не гарантує доставку.

Потім усім стало ясно, що менеджмент хоче, щоб ми поєднали в собі і UDP і TCP, тобто гарантували доставку для високої швидкості поставки нових фіч.

— У нас є колектив розробників, який, так вже склалося, поділився на команди. На чолі кожної команди стоїть Team Lead, і майже завжди це хтось із наших Senior Developer'ів. Над нами є CEO і CTO. Так само у нас тут всі інші незрозумілі люди, які постійно переривають процес і вносять свої корективи. І, от, начебто б всі розробники начебто постійно зайняті розробкою, але хтось весь час простоює або перевантажений і/або попутно зайнятий рішенням якого-небудь з типів переривань: від керівництва, від саппорта, від технічного боргу. Тобто, ми постійно маємо справу з яким небудь FuckUp, який відбувається тому, що просто все так склалося. У нас начебто є процес, але він не вирішує проблему того, що коли Ти хочеш писати код — ти не можеш, а коли можеш, то вже не хочеш, так як втомився, поки не міг, і взагалі вирішував інші «важливі» завдання. Хто на мітинг пішов, хто за чаєм, і ось так от плов все ніяк не звариться до потрібної кондиції.

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

— Я пропоную об'єднати команди по іншому. На чолі команди не може стояти Team Lead. Тобто, все буде як і раніше, тільки керувати командою буде не Senior Developer, а хто-небудь більш-менш грамотний із Middle або навіть перспективних Jun'ів.

Це як це?

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

Наприклад, у нас є Pool висококваліфікованих і компетентних фахівців, давайте так обзозначим Senior Developer'ів. Далі у нас є менш компетентні, які дуже хочуть «рости» і стати більш компетентними. Але їм постійно не вистачає ні часу «старших» братів, ні поваги менеджменту, ні, тим більше, розуміння процесів.

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


І тоді, через рік у нас буде не 8 Сеньйорів, а мінімум в два рази більше. Ми ж вже два роки не змінюємо перспективи. Наймаємо начебто відмінних сеньйорів, а джуни в мідл майже не ростуть, так і мидлы майже не ростуть у сеньйорів.

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

— Уяви, Дема, що Ти зміг би працювати, саме Працювати, а не просто сидіти в скайпі щогодини відриваючись на кодец, не по 20, а по 30-40+ годин в тиждень? Ти ж і так працюєш по 60+ годин тільки з-за того, що постійно хто-небудь врзывает Тобі мозок, а робота стоїть, а зробити її треба, ти ж відповідальний!

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

— Уяви, Васю, що Ти б був начальником у Деми? У Тебе ж би всі справи спорились, Може і Аніта з акаунтів, нарешті б Тебе помітила? А там, дивись, Ти б побачив код Деми з-за спини, і зрозумів би, що в ньому немає ніякої «магії».

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

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

Варя просяяла, так як вона зрозуміла, в чому проблема. В основному вона працювала з Аристархом, тим ще Хіпстером: «коммандиром» FrontEnd команди. Особистість він був вельми імпозантна, і код у нього був чудовий. Проблема була тільки в тому, що йому колись було його писати, і велика частина завдань вирішувалася його підлеглими, і у нього навіть не завжди був час на Code Review. Так як він був чи не єдиний чоловік, який розумів процес створення красивостей «в комплексі», то деколи навіть і відділ продажів контактував з ним безпосередньо, минаючи всю технологічний ланцюжок. Це був єдиний чоловік в комманде, який міг зрозуміти дизайнера відразу, не перепитуючи, і не проміжна. Звичайно, вся його ватага на нього молилася, але Варя страждала. Вона розуміла, що половина його підлеглих чекають коли ж він зверне увагу на нею, Варею, знайдені баги.

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

До вечора був готовий «меморандум», який вони потайки приклеїли на SCRUM дошку.
У меморандумі було лише наступне:

Un-FuckUp-able Development Protocol (UDP)
  • Team Lead !== Team Manager
  • Team Manager == Middle Developer
  • Senior Developer == Code Leader (GOD of Code)


І QR-код на «по-швидкому» підготовлений документ, викладає основні принципи вчорашньої PR компанії ідей Джона.

***

Do You like my Story, man?

Звичайно, у них було все, і метрики продуктивності, і Grade'и, і SMART і все таке інше важливе-преважное, що ми так сильно любимо. Але все ж ми розуміємо, що хочемо, чи не так?

Sincerely Yours John…
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.