«Почему ж всё так плохо?» — каждый раз я задаюсь этим вопросом, когда приходится иметь дело с очередным кодом, продуктом или API, созданными для внутренних нужд в непрофильной организации.
В профильных дела обстоят получше, но далеко не всегда: в коробочных тиражируемых решениях чаще лучше, чем в проектной разработке. В продуктах одного заказчика, обычно, хуже всего.
И деньги ничего не решают: ужасный код и ужасные продукты пишут как маленькие бедные ВУЗы, у которых денег хватает только на рабский труд аспирантов, так и крупные и богатые компании, включая IT-компании, включая зарубежные: несколько раз сталкивался с кодом, который писали зарубежные подрядчики и каждый раз от него хотелось рыдать и биться головой об стену.
Организация может декларировать строгие стандарты, нанимать дорогостоящих разработчиков, вводить регламенты и методологии, надувать щеки на совещаниях и громогласно обличать «неправильное решение» в чужом продукте. И продолжать делать ужасные продукты с ужасным кодом, вопреки высокой квалификации своих разработчиков и очень правильными и нужными регламентами и стандартами.
Я занимался разработкой ПО в нескольких организациях и по разным причинам несколько раз перенабирал команду с нуля. В итоге пришел к выводу, что качество продукта зависит только от культуры разработки. Всё остальное, включая методологии и стандарты — это инструменты: они необходимы, но одних их не достаточно.
Культуру разработки можно сравнить с экосистемой: как сад или аквариум. Крепкая, здоровая культура обладает запасом прочности, чтобы оздоравливать обитателей экосистемы, избавляться от вредителей, прощать небольшие ошибки ухода, сглаживать стрессы и на выходе все-равно получать отличный результат. А больная культура сводит на нет все усилия, заражает и губит даже самые здоровые и крепкие саженцы.
Когда в коллектив со сложившейся культурой разработки приходит новый инженер, он либо принимает культуру, либо коллектив его отторгает. Пристроиться и паразитировать на коллективе со здоровой культурой разработки почти невозможно — он моментально вычисляет необучаемых, ленивых и безразличных разработчиков. Сперва их попытаются наставить, объяснить, научить, а потом к вам потянутся по-одному ваши сотрудники «поговорить про нового коллегу». И наоборот, увлеченных своим делом, готовых развиваться и сотрудничать такой коллектив принимает радушно и вот уже они уже вместе ходят обедать, общаются вне работы, знакомятся семьями, приглашают друг-друга на домашние мероприятия и помогают с бытовыми делами.
Культуру нельзя купить или украсть, сманив разработчика. Как нельзя забрать из сада плодоносящее дерево: если оно и переживет пересадку, прежних урожаев вы уже не дождетесь.
Культуру нельзя ввести распоряжением. Это ежедневная работа, создание микроклимата, отслеживание параметров, обучение, наставничество. Как только-что запущенный аквариум требует постоянного отслеживания параметров воды, постепенного, но своевременного заселения, гибкой подстройки параметров освещения, аэрации, внесения удобрений и микроорганизмов. Зато потом, когда культура окрепнет и стабилизируется, она начнет работать на вас.
Если культурой не заниматься, она образуется сама и скорее-всего это будет деструктивная, нездоровая культура.
Чем крупнее экосистема, тем стабильнее ее культура. Если у вас 1-2 разработчика, культура разработки очень быстро деградирует несмотря на все усилия. Минимальное количество разработчиков команды, чтобы сформировать в ней стабильную позитивную культуру — 3-5 человек.
Я неоднократно наблюдал, как стремительно деградирует культура разработки, когда программистов остается меньше трех. Вчера еще отличные разработчики начинают писать настолько ужасный код, что после восстановления команды и культуры, его приходится полностью переписывать.
Даже в крупных и стабильных коллективах, сложившуюся культуру можно легко разрушить, спровоцировав её деградацию, неправильными организационными решениями: неправильно-выстроенной мотивацией, попустительством, требованиями бездумно подчиниться решению без объяснения и убеждения в его целесообразности, постоянными горящими задачами, которые нужно «сделать вчера и не важно как», решениями вида «сделать как-нибудь срочно, а потом переделаем по-нормальному».
Крупные коллективы со сформировавшейся деструктивной культурой будут яростно сопротивляться изменениям. Отторгать или саботировать стандарты и регламенты, либо же соблюдать с сохранением некачественного результата.
Я сталкивался со следующими признаками деструктивной культуры:
— Безразличие: «я делаю так, как мне сказали», «мне за это не платят», «главное чтобы на сдаче-приемке работало».
— Злой сарказм и травля в коллективе.
— Ненависть к заказчику и пользователю: «копытом буквы набивают», «неправильно используют продукт», «жмоты», «сами не знают, чего хотят».
— Ненависть к руководству: «Некомпетентные эксплуататоры».
— Ненависть к коллегам: «Криворукие дураки».
— Саботаж через исполнительность: «Поставьте мне четкую задачу и дайте инструкцию, как ее исполнить», «В регламенте эта процедура не прописана» и т.п.
— Бездумное исполнение пожеланий заказчик: «Мне сказали — я сделал. На документирование, комментирование, проектирование и прочие глупости нет времени. Заказчик хочет, чтобы все работало ровно так, как он попросил, самым дешевым и быстрым способом. Про развиваемость, обслуживаемость и обновляемость заказчик ничего не говорил».
— Излишняя концентрация на внешнем функционале: «Главное, чтобы работало».
— Излишняя концентрация на архитектуре, в ущерб функционалу: «С точки зрения архитектуры ввод всех этих данных в одном окне сделать нельзя».
Все эти признаки, как сорняки, постоянно появляются даже в здоровом коллективе. Нужно контролировать их рост, проводить разъяснения, обсуждать мотивацию и эмоции других участников проекта, чтобы развивались понимание и эмпатия. Объяснять или давать возможность столкнуться с последствиями непродуманных решений, чтобы важность тех или иных правил подкреплялась собственным опытом.
Из моего опыта, проще всего вырастить культуру начав с 3-х разработчиков, с которыми нужно общаться ежедневно и непрерывно, вместе смотреть код, обсуждать все архитектурные решения. Потом, когда разработчики начнут сами принимать верные решения, надо ослаблять контроль — с этим нельзя затягивать, иначе вырастите «бездумных роботов» и постоянно будете заниматься мелочной опекой.
После этого нужно добавить еще хотя-бы двоих и проследить, как они адаптируются. Скорректировать этот процесс: беседовать с разработчиками, чтобы они не принимали новичков в штыки, относились по-доброму, но и не занянчивали их.
Новых людей лучше добавлять по-одному. Так у них не будет возможности замкнуться друг-на-друга и организовать внутри коллектива мини-партию. Мини-партии стажеров опасны тем, что они противопоставляют себя коллективу. Постоянно ищут, в чем их обделили, как в анекдоте про жадную слепую девочку, которой родители наварили целый таз пельменей («Представляю, сколько они себе нафигачили»).
Мне удобнее нанимать джуниоров: их обучение занимает больше времени, зато они легче адаптируются к культуре, с меньшей вероятностью начинают ей сопротивляться и пытаться разрушить. Главное, отследить момент, когда джуниор вырос и поднять ему зарплату, иначе вы его потеряете: поднимать зарплату, когда человек пришел с заявлением, чаще-всего поздно — он уже принял решение, принял job offer. Даже если он останется, «заряд мобильности» снова выстрелит в ближайшие месяцы. Пытаться сэкономить на зарплате, затягивая повышение вслед за ростом компетенции и рыночной стоимости — плохая тактика, к тому же, она плохо сказывается на культуре разработки.
Сформировать здоровую культуру разработки — дело хлопотное и небыстрое. Но усилия окупаются сторицей и качеством кода, и лояльностью, и упрощением адаптации новых сотрудников. Поэтому оно того однозначно стоит.
Автор: alexdjachenko
