Хочу поделиться реальной историей, ну и заодно возможно услышать мнения других участников хабрасообщества. Это небольшая история о том, как агрессивное внедрение методологии разработки Agile (Scrum) в отдельно взятой российской IT компании послужило началом исхода из компании лучших разработчиков. Обычно в статьях про Agile рассказывают, какая это классная и полезная методология, и вообще — это лучшее, что было придумано в этом направлении. Возможно, эта статья поможет взглянуть на Agile с другой стороны, ведь у любой монеты, как оказалось, есть две стороны.
В общем, в 2010-м году была основана одна российская компания (что-за компания конкретизировать смысла нет), работала она в сфере IT-разработки (ПО для банковских продуктов).
Как водится, поначалу всё работало практически в режиме стартапа, но, тем не менее, компания уверенно стояла на ногах и быстро себя окупила. Постепенно число сотрудников компании росло, менеджеры, фронт и веб-разработчики, вот их уже перевалило за 50 человек и открылись первые представительства за рубежом.
По мере того, как росло число непосредственно разработчиков, проект привлекал инвестиции и нанимал новый управленческий персонал; появлялись технические директора, HR-отделы, куча административного персонала и бесчисленная армия менеджеров всех мастей.
Разработчики делали своё дело, проект был отлажен до мелочей; вроде бы всё было хорошо и ничего не предвещало резких изменений. Задачи ставились и выполнялись, за пять лет состав разработчиков сильно не изменился, через 5 лет после основания компании из неё не ушел почти ни один разработчик, стоявший у истоков. А это как по мне показатель того, что людям было комфортно работать в компании.
В один прекрасный момент руководство компании решило попробовать новомодную для России методологию разработки. Был выбран Agile (Scrum), в компанию нанят скрам-мастер, все разработки были переведены в TargetProcess. С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а так-же получить понимание, на что тратят время разработчики. К слову, о разработчиках. Это действительно гениальные люди, владеющие поистине не малым стеком технологий и действительно переживающие за свой проект, знающие о сути самого проекта гораздо больше, чем менеджмент.
Я, конечно, прекрасно понимаю, что времена меняются, и раньше, возможно, разработка проекта была чем-то вроде творчества. Теперь это отлаженный бизнес-процесс, целью которого является зарабатывание денег. Но доведенный до апофеоза этот процесс может подавить в разработчиках тягу к креативу и заинтересованности в развитии проекта.
Поначалу, после внедрения новомодного Скрама, все радовались его логичности и внешней простоте. Всё понятно, делим процесс разработки на спринты, получаем от менеджеров user-story (задачи что делать), включаем их в те или иные спринты, в конце спринта делаем ретроспективу (смотрим что сделали, и что пошло не так) и зацикливаем этот процесс.
Но потом всё переросло в то, что отдел разработки превратился из ядра компании, приносящего деньги, просто в инструмент, наподобие отвертки или молотка. Менеджеры придумывали задачу, скидывали в IT-отдел и ждали реализации, попутно считая время, затраченное на разработку и тестирование. Разработчикам и тестировщикам было велено списывать время на выполнение задачи в TargetProcess. Менеджмент начал конвертировать задачи во время их выполнения и естественно в стоимость. Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую? Возможно, отдел разработки с точки зрения бизнеса всегда выглядит как ленивые сотрудники, которые хорошо, если бы смогли работать втрое, а лучше в пять раз быстрее, чтобы снизить расходы на разработку и увеличить её скорость.
С их точки зрения всё, конечно, логично: быстрее сделали – а значит, понесли меньше расходов, быстрее выполнили контракт, получили деньги и премии. Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление со стороны менеджмента и отчет за каждый час рабочего времени. Стали возникать вопросы в духе «почему вы потратили целый день на разработку или тестирование того-то»?
После месячного негодования страсти немного поутихли, и отдел разработки понемногу свыкся с участью «отвертки».
Разработка ПО – это такое ремесло, которое тесно связано с творчеством, одну и ту-же задачу можно сделать либо хорошо, либо подойти творчески и сделать очень-хорошо.
Тут вспоминается выступление bobuk о том, как нужно обращаться с разработчиками. Ответ: как с детьми. Я, конечно, не считаю, что так нужно обращаться со всеми подряд, но нужно учитывать, что резкое изменение правил игры в компании может понадобиться не всем.
Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало. Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
В итоге вся эта система стала приводить к маленькому локальному коллапсу. Разработчики растеряли весь энтузиазм и стали относиться к разработке формально. Есть задача – делаем, нет задачи – не делаем. Кроме того, почасовой отчет по времени оставлял привкус того, что за твоей спиной непрерывно кто-то стоит и наблюдает, как ты нажимаешь кнопки.
Естественно, с точки зрения Менеджмента ситуация была более радужной, они получили полный отчет по времени, затраченном на разработку любого проекта, и понимание того, кто чем занимается почти в реал-тайм.
Но разработчики — тоже люди, и начали не выдерживать. Буквально за месяц компанию покинули 3 ключевых разработчика ядра. Замену которым в настоящий момент взять просто негде. Они работали в компании с самого момента основания и фактически сделали компанию тем, чем она является сейчас. Нагрузка на остальных разработчиков стала возрастать в геометрической прогрессии; отдел разработки зашатался как карточный домик, разработчики, которые работали в компании по 5 лет, стали уходить, т.к. перестали чувствовать себя частью компании, превратившись в «отвертку».
Резюме
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
Агрессивный переход на такие потоковые методологии разработки приводит к «формализации» отношений внутри компании. Результатом резких внедрений стало то, что менеджмент теперь лучше видит, что происходит в компании, но ключевых разработчиков в компании уже нет.
Говорить о том, что эти сотрудники виноваты сами, тем, что не смогли адаптироваться, или поступили высокомерно – как по мне, так это ошибка. Возможно, сам процесс внедрения Agile был организован неверно, но, так или иначе, свою черную сторону этот процесс имел.
Автор: Keks650
