Недавно после очередного 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+ часов только из-за того, что постоянно кто-нибудь врзывает Тебе мозг. А работа стоит, а сделать её надо сегодня, код не ждёт, ты же ответственный!

Конечно, Дёма не мог не согласиться, он уже две недели жену и дочь видел только спящими. Он очень хотел как-нибудь всё же уйти домой вовремя, сентиментальность.

— Представь, Вася, что Ты был бы начальником у Дёмы, а не наоборот? У Тебя же бы все дела спорились, Может и Анита из аккаунтов, наконец бы Тебя заметила? А там, глядишь, Ты бы увидел код Дёмы из-за спины, и понял бы, что в нём нет никакой особой сеньёрской “магии”.

Конечно у Васи загорелись глаза. Он и представить себе не мог это в самых радужных снах, руководить отделом! Уж он то знал точно, как всё устроить, если бы у него только были ещё и такие подчинённые как Дёма, он бы давно всё порешал.

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

Варя просияла, так как она поняла в чём проблема. В основном она работала с Аристархом, тем ещё хипстером: “коммандиром” Front-End-щиков. Личность он был весьма импозантная, и код у него был великолепен. Проблема была толкьо в том, что ему некогда было его писать, и большая часть задач решалась его подчинёнными, и у него даже не всегда было время на 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…
Поделиться с друзьями
-->

Комментарии (15)


  1. yusman
    04.08.2016 18:14
    +2

    Офигенная статья и интересный подход. Спасибо!


  1. VolCh
    04.08.2016 20:42
    +1

    Эх, завидую сеньорам — 40, а то и 60 часов в неделю кода…


    1. VolCh
      04.08.2016 20:43
      +1

      И никаких бизнесом с идеями


    1. wentout
      04.08.2016 21:39

      Можно пробовать, не сломя голову, нужно всё же думать всегда До, а не После. На личном опыте могу подтвердить, что не 146%.


  1. TimsTims
    04.08.2016 22:28
    +1

    Звучит все красиво, но в чем может быть подвох?

    Senior'ы услышав глупость от Junior начнут слать его лесом, не слушать, всегда вступать с ним в конфронтации чисто из-за того, что не могут принять, что Jun ими командует, и вместо подчинения — будут дальше забиваться в свой угол и нерационально использовать время...?

    Либо Jun став таким окрыленным от *повышения* начнет зазнаваться и вместо роста и прогресса будет думать, что он здесь *босс* и он уже всего добился, и нафиг ему что-то кодить, вон есть же *программисты*


    1. wentout
      04.08.2016 22:58
      +1

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

      Но вот Общается с Менеджментом в основном уже не он. Проясняет требования тоже не он, а человек в этих вопросах настолько же компетентный.
      Вы же не будете спорить, что если человек дожил до позиции Мидла, то он уже чего-то стоит. Как правило он понимает матлогику, теорию систем, принцип обратой связи и вообще — может выстроить коммуникацию. Его уровень компетенции уже вполне позволяет принять на себя весь баласт общения с менеджментом. К тому же, как правило, он всё уже видел и слышал раньше, понимает как работает его команда, кто главный, кто что может, и вообще — спектр задач целиком ему знаком. Он и менеджмент весь уже знает, включая все «повадки». Он не ляпнет, и его не подловят, его уже не раз ловил на слове его Team Lead, и он уже не раз сидел до глубокой заполночи решая сложную задачку. В общем, это такой уже опытный «боец» со стажем переговоров. И, конечно, он вполне в состоянии организовать работу, чтобы разгрузить Сеньора для решения действительно стоящих проблем, кроме: руководство командой и принятие управленческих решений.
      То есть, senior так полностью высвобождается от всего мозго… бства, и способен посвятить себя команде, продукту, думанию, коду и ответственности за результат. Но если уж случается лажа, то отвечать будет менеджер команды, то есть Мидл. Так как это он упустил нюасы, не договорился по срокам, не увидел перегруз, не нажал и так далее и тому подобное. Как показывает личный мой опыт одного раза достаточно почти всем, самые упёртые переживают три итерации, дальше уже осечек нет, потому, что или мидлу всё ясно, или он выгорел и уволился. То есть, единственная возможность для мидла начать писать код — стать сеньором. Да — потовыжималка, но он же Мидл, это его работа. А если справился — возьми с полки пирожок, можешь приступать к задачам сеньора, молодец, пиши, наконец, свой любимый код, подставляй другого новичка.

      Вы действительно думаете, что юный Джун сможет зазнаться? Ни разу такого не видел, его садят за парту с первого полу-слова, даже не синьоры, а менеджеры, он же вообще ничего не знает о процессе создания добавленной стоимости и product value для него пустой звук.
      Перспетивный джун — это почти мидл, так что тут, думаю, всё тоже самое. Такой Джун может руководить командой мидлов, в которой Senior из других команд как внештатный консультант, набегами, помогает с технологической составляющей.

      А подвох в том, что не каждый сеньор хочет писать код. Красиво же звучит Senior Developer. Да и платят неплохо. Только вот менеджерить такому сеньору гораздо интересней, чем кодить. Он всё знает, всё умеет и всё может, но уже ничего не хочет, так как перегорел. Выход, как Вы понимаете — очевиден. Он уже не Senior, а Мидл, или вообще Project Manager — то есть по другую сторону силы. В общем, с ним надо ловить момент, и успеть повесить новую морковку, пока человек до конца не сгорел. Он может вернётся в код, когда отдохнёт на менеджерской работе, а может и нет, но Травить его кодом бессмыслено, а давать молоко за вредность, переводя на другую роль — очень даже повысит его эффективность.


      1. i_user
        05.08.2016 12:24
        +1

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

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


        1. wentout
          05.08.2016 12:35

          Да, конечно. Не предлагаю же здравый смысл отменять. Можно же, что в начале пути ещё не совсем опытного Мидла Team Leader aka Senior садятся с Project Manager'ом вместе и выстраивают план задач на Спринт или Водопад, попутно объясняя Мидлу за чем конкретно и как следить, что кому поручать, и что будет происходить. Почему не попробовать? Не зайдёт — ок, значит так не получится в этой среде. Я ж не утверждаю, что оно всегда работает, но оно работает. В 2007 году у меня половина команд была такая. И всё было ок, т.к. Senior занят разработкой, и отвечает за качество перед менеджментом, но не отвечает за «упустили нюансы», «мы тут хотим ещё вставить требование», «от заказчика пришла разнарядка», «надо провести приёмо-передаточные испытания», «ТЗ не утвердили» и т.п.

          Работа программиста скорей всего не сложней, но Вы же не будете отрицать, что она Требует сосредоточенности?


  1. gaki
    05.08.2016 05:04

    Слуште, вот откуда пошла эта мода писать личные местоимения с большой буквы? «Представь, Дёма, что Ты смог бы...». Дёма — Господь Бог?


    1. keksmen
      05.08.2016 09:30
      +1

      Откуда вам знать, что это не имя? Имена всегда с "большой" буквы начинаются, вне зависимости от контекста.


      1. gaki
        05.08.2016 11:05
        +1

        Корейский интерн Чон Пак Ты?


        1. wentout
          06.08.2016 03:04

          Образы собирательыне, как Вы понимаете :)
          У меня только в трудовой книжке 24 записи, и это далеко не полный список. У системного аналитика Работа же проектная. Сделал, порадовался, отметили, контракт завершён, поддержка справится по текущей документации — всё. Максимум какие-нибудь ещё уточнения некоторое время, но в целом потом уже как-то без меня обходятся. Был один период, когда у меня в неделю по 3 ТЗ выпускалось, не сам, конечно, с товарищами, но в конце концов так замучался, что решил переквалифицироваться в JS кодера. Вот, 5 лет уже заметочки на полях кропаю, навык буквоедства же остался, что ж ему, пропадать, чтоль.


    1. wentout
      05.08.2016 11:06

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


      1. gaki
        05.08.2016 13:59
        +1

        Класс, как у вас всё запущено! У меня когда-то был бзик закрывать все скобки и кавычки в предложении и проставлять все точки в конце. Т. е.:
        Вася сказал: «Коля сказал: „Идите вы в задницу.“.». — хотя по-правилам в конце предложения нужна одна точка и одна кавычка, но тогда же в предложении первая кавычка останется незакрытой, и два предложения без точек!


        1. wentout
          06.08.2016 02:59

          Слушай, прикольно, надо будет попробовать как-нибудь. У меня есть заветный друг, который всё время меня троллит за Ты с большой буквы, приколю его ещё и этим.