Итак, я зашел в раздел с постами и там увидел диаграмму (пик рилейтед).
А под ней ссылка на статью «Разработчики - в стойло, менеджеры в - башню из слоновой кости: создаем касту избранных в 4 шага».
Всего 3 комментария, 1900 просмотров и целых 37 пальцев вверх. Отличный результат, я уверен, тут нет никакой накрутки. Статья очень нажористая, рекомендую ознакомиться.
Нукси (имя изменено) поведала нам, как в отделе занимающемся дашбордом, где в отделе из 10 человек четверо менеджеры, перестать иметь хоть что-то общее с разработкой и преподать это как улучшение.
Из оригинальной статьи создается впечатление, что эти 4 менеджера управляют галактикой, но на самом деле, просто устраиваются поудобнее.
Уничтожаем экспертизу
Пт. От многофункциональных сотрудников — к профильным
Проблема:
...Сбор информации о клиентах, услугах, потреблении и оплатах производился разными системами, данные агрегировались в таблицах с разными структурами, не связанными общими признаками и логикой. В этих проектах для правильной и полезной аналитики иногда приходилось объединять разные вселенные.
Иными словами, для работы нужны сотрудники понимающие смежные предметные области, что не удивительно, если мы имеем дело с анализом данных.
Решение:
...Основная задача разделения заключалась в том, чтобы разработчики концентрировались на создании отчетов и обеспечивали непрерывный поток результативной работы, а методологи общались с заказчиками, собирали ТЗ для разработчиков…
...Это позволило нам не распыляться в многозадачности, а сфокусироваться на своем направлении.
Я прочитал только первый абзац и уже не могу.
В постановке проблемы вы написали, что для работы требуются эрудированные сотрудники, знакомые со множеством деталей из разных предметных областей, и сами же разделяете ответственность таким образом, чтобы сузить понимание смежных областей до минимума.
Теперь, отношения в отделе строятся не в горизонтальной, а в вертикальной плоскости. Менеджеры скидываю ТЗ вниз, а разработчики выполняют то, что им написали.
На основе ваших же слов, Нукси, вы не только не смогли найти в текущем подходе проблему, вы сразу перешли к подрывной деятельности.
Все должны быть виноваты
Пт. Определяемся с зонами ответственности и визуализируем бизнес-процессы
Поскольку задачи между аналитиками даже в двух разных командах концептуально пересекаются, перед нами встала следующая проблема. Не всегда было ясно, кто и за что должен отвечать. Например, кто отвечает за корректность данных? Методолог, который выпускает дашборд, разработчик, которые оперирует этими данными, или инженер базы данных, который организовывает сбор данных. Вы можете сказать, что это очевидно. Но, как показала наша практика, у каждого специалиста может быть свое мнение на этот счет.
Теперь менеджеры скидывают ТЗ вниз, но теперь разработчики просят внести правки в ТЗ прямо во время спринта. Во время написания кода, декомпозиции предметной области, всплывают недочеты. Непорядок, давайте это исправим.
...Нам было важно сделать так, чтобы ответ был одинаково очевиден для каждого участника процесса. Только так мы могли обеспечить качественное выполнение проектов в срок.
То есть пошел поиск виновных и принуждение через вину.
Смысл в том, что путем сложных согласований и выкручивания рук добиться от коллег письменного или устного «Да» под проектом.
Разные менеджеры используют разное напряжение и модели паяльников, но результат один.
Нужно заставить всех согласиться с выполнением именно этой версии проекта. Далее, если проблемы с ним таки всплывут, апеллировать к тому, что под ним все подписались. Ты же подставишь команду?
Это классический трюк ленивого менеджмента, он работает не только с коллегами, но и с заказчиками, они же подписались. Решение было принято, подписи сделаны, печати поставлены.
Как выкручивание рук работает в Selectel
Для обеспечения прозрачности мы подробно прописали бизнес-процессы в команде по ролям: кто и что делает на определенном этапе, какой ожидается результат.
Далее приложена диаграмма, которая меня заинтересовала с самого начала. На ней менеджер вместе с заказчиком проектируют решение в течение двух недель. Разве это не прекрасно?
Схема отличная и рабочая, если клиенты имеют понятие что конкретно они хотят и знают, как это донести до менеджера, если менеджеры имеют понятие о разработке и понимают клиента, а разработчики имеют понятие, что имеют ввиду менеджеры.
(То есть, схема не рабочая)
Хайндсайт 20/20
После составления схемы выше, у менеджера случился хайндсайт 20/20 и ему пришло в голову еще 3 гениальные мысли. И со всеми этими мыслями у меня непонятки.
Невозможно измерить несуществующее
1.Не хватает планирования загрузки, задачи распределяются стихийно
Чтобы примерно прикинуть длительность разработки, можно сесть за стол с блокнотом и подумать.
Разбить проект на задачи, из опыта прикинуть, сколько времени уйдет на решение каждой из них и выдать DateTime[] в виде кривой нормального распределения, с разбросом оценок от месяца до полугода.
Нормальному менеджеру такой ответ не понравится, он с красными глазами будет на вас грозно смотреть, бить копытом и рычать. Это нормально. Он не кусается, лишь пытается убедиться, что вы не бездельничаете.
Единственный вариант точно оценить время, затраченное на разработку это начать и завершить разработку.
Но так как в случае с Селектелом декомпозицию осуществляют менеджер с клиентом, неудивительно, почему такие идеи приходят в их головы.
Вам платят не за сроки
…а значит, мы не можем назвать заказчику даже примерные сроки окончания проекта.
Отдельным пунктом идет идея о том, что заказчику необходимо знать сроки. А деньги вам платят тоже за сроки?
С одной стороны, менеджменту хватило яиц продавить изменения, с другой стороны, их не хватило, чтобы объяснить клиенту, что сначала мы выпустим MVP, и если это то, что заказчик хотел, будем заполнять функциональностью, которая для него более приоритетна.
Вместо этого, клиент по-классике выломал руки менеджеру и заставил дать сроки.
Ваша задача как менеджера заключается только в том, чтобы донести эту простую мысль до заказчика. Если вы не смогли этого сделать, значит вы проф. непригодны.
Потеря времени и денег
Так как клиенту «дали сроки», то появляется время, которое после прототипирования можно бесцельно потратить. Например, на документацию прототипа или кодревью.
Ревьюить и документировать будут, естественно, весь код, в том числе тот, который будет переделан или выброшен. Вся эта затея со сроками и плейсхолдерной активностью лишь увеличивает стоимость проекта для заказчика.
Проблема ревью по факту сделанной работы в том, что это ревью не происходит, когда оно наиболее необходимо - во время принятия решений.
Откладывать ревью в конец спринта не только бесполезно, но еще и вредно, бо человек уже принял серию неверных решений и место остается только для критики.
Было бы хорошо, если бы каждый разработчик мог бы проконсультироваться с другим или посидеть над проблемой вместе, подумать. Этому помогает, например, парное программирование.
Но настоящие агиле подходы делают работу над задачей по определению Нукси, более «Стихийной» и «Непредсказуемой».
Четкость ведения задач обеспечивают чек-листы
Чтобы прочно внедрить вредные практики, пришлось делать делать чек-листы. Сам чеклист это отдельный позор для организации. Смотрите на него под спойлером.
Чеклист, без которого можно обойтись, если ты делаешь все правильно
Судя почек-листу, они документируют еще и эндпоинты в своем API. Тут либо менеджменту swagger’а было недостаточно. Либо у них не было swagger’а, что показывает, что в Selectel помимо плохих менеджерских практик, есть еще и плохие инженерные практики.
Слежка - дело рук отслеживаемого
Следующая проблема, которую мы решали, — это хаос при заведении задачи, их стихийное принятие в работу. Не всегда было понятно, какой задачей на текущий момент занимается конкретный член команды…
В команде всего 10 человек, из них четверо - менеджеры. Все четыре менеджера не смогли уследить за 6 программистами. Если это не роспись в своей проф. непригодности, я не знаю, что это.
Дальше статью разбирать нет смысла, далее следуют логические выводы, закольцованные на себя и длинная тирада о том, что деградацию рабочего процесса и круговую поруку все хотели и все поддержали.
Вы сделали все неправильно
Я люблю правильные подходы, например, TDD.
Пока ты пишешь тесты, получается и дешевле, и качественнее потому, что выходит меньше брака. Делая тесты наперед, ты реже ошибаешься, а исправление ошибок становится быстрее. Тесты так же служат своеобразной документацией к коду и составляют фундамент для крупных безопасных изменений.
По моему мнению, Agile подход это TDD для менеджмента. Мы получаем быструю обратную связь, быстро вносим правки и не тратим время на реализацию нашего недопонимания.
Быстрее цикл обратной связи, меньше «бракованного» общения с клиентами, меньше работы менеджерам и разработчикам. Меньше издержки на нашу компанию и нашего клиента.
В селектеле, возможно, практиковали агиле, на это намекает словосочетание «Двухнедельные спринты», но Нукси сделала все, чтобы угробить остатки.
В конечном итоге они всем отделом приползли к ухудшенной версия ватерфолла, где задачи спускает не архитектор, знакомый с кампанией и коллективом, а заказчик с менеджером.
Фейл селектела не только в менеджменте
Идиотический чек-лист продавить было почти невозможно, если бы разработчики изначально обеспокоились бы CI/CD и acceptance testing’ом. Если вы уже занимаетесь TDD, настроить пайплайн это дело двух минут, а менеджера отпугнет. Скорее всего, они не занимались ни тем ни другим.
Более того, разработчики поделились на разработчиков бизнес-логики и разработчиков базы данных.
Если даже с помощью гугла, вы не можете написать хранимую процедуру, а вместо этого, целую неделю отдельный человек пишет её вам, возможно, разработка это не для вас, и ваше место за плитой во «Вкусно и точка».
Если все, что вы умеете, это писать хранимые процедуры и добавлять таблицу в базу, то у меня тоже плохая новость. Ваша профессия - сисадмин, в лучшем случае. В связи с этим, возможно, вам стоит пересмотреть свои зарплатные ожидания.
Придя в нормальный коллектив, сложно себе представить, чем бы все эти бездельники занимались.
Задача как менеджера, так и программиста, помочь бизнесу заработать больше денег и сократить издержки. Поэтому вы, как разработчик делаете все по-красоте, либо эффективный менеджер увидит слабость и начнет её эксплуатировать.
Выбор стоит так: либо технократия, либо бюрократия.
Дизайн наперед не работает
Практика делать весь дизайн наперед не работает и работать не будет. Ни заказчик, ни менеджер, ни разработчик не понимают что делают и говорят. Это нормально, так всегда было.
Если вы делаете весь дизайн наперед как Нукси это делает, за эти поставленные 2 недели не написана ни одна строчка кода. Это не только трата времени на дизайн, который не взлетит, но дизайн, который априори не исходит из реалий стека и языка.
Правда декомпозиции в том, что на самом деле, разработчики стучатся головой об проблему до тех пор, пока эта декомпозиция путем проб и ошибок, не появится сама.
Но в итоге мы имеем время, потраченное на менеджера, чтобы он мог сказать, что чем-то занимался.
Схитрить не получится
Все, у кого есть и все, кто умеют свой думать, понимают, что чем больше у тебя работы, тем больше на тебе нагрузка.
Если от перестановки слагаемых у вас меняется сумма, значит в уравнении где-то ошибка.
В селектеле время, которое ранее уходило на коммуникацию, теперь уходит на печатание кода, который все равно придется переделывать.
В одной компании (называть не буду), успех менеджмента определяется количеством информации, которой они поделились с остальными.
Например, если менеджер филиала находит оптимизацию, и эта оптимизация заходит остальными филиалам, значит, менеджер действительно занимается менеджментом.
Он сокращает излишние расходы, добивается большего, используя меньшее.
Если вы добавляете бюрократию, значит вы занимаетесь не менеджментом. Если вы меняете агиле на ватерфол, значит вам не место в профессии.
Послесловие
Разбирать такой материал крайне сложно, тут негде ставить пробы. Каждое неверное решение тянет за собой хвост из мгновенных и отложенных последствий.
Оригинальная статья написана в хронологическом порядке, по мере принятия решений. Но логика этих решений не следует из возникающих проблем или из стремления достижения результатов.
Реальная ситуация, скорее всего, представляет серию арбитрарных решений в сугубо личных целях, а проблемы, скорее всего, были высосаны из пальца или додуманы, чтобы продать реформы вышестоящему начальству.
Подозреваю, что мы имели дело с частным случаем Job Security Driven Development’ом, только со стороны менеджмента. Менеджер поняла, что в коллективе, где разработчики общаются с заказчиками напрямую, она выполняла роль не большую, чем девушка на ресепшне.
Если посмотреть на оригинальный материал с этой точки зрения, то все эти изменения начинают нести гораздо больший смысл.
Как же хорошо, Нукси, что я работаю не с вами.
Автор:
nneeoo
