Хочу поделиться историей, ну и заодно услышать мнения других участников хабрасообщества. Это небольшая история о том, как агрессивное внедрение методологии разработки 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 был организован неверно, но, так или иначе, свою черную сторону этот процесс имел.
