«Первый шаг к совершенствованию — это стандартизация. Там, где нет норм, не может быть улучшения.»
Канбан и точно вовремя на Toyota
В этой статье вас ждёт мысленный эксперимент, в ходе которого я покажу, что может дать компании стандартизация разработки программного обеспечения, и проблемы, к которым она может привести. Статья не претендует на полный охват этой большой темы, но, я надеюсь, в ней будет тот минимум, который позволит вам по-новому взглянуть на разработку в своей компании.
Выводы и практические рекомендации, о которых я пишу, получены из моего опыта стандартизации в одном из крупнейших IT-разработчиков в России. Поэтому все названия вымышлены, а совпадения случайны.
В тексте вы встретите некоторые термины из фронтенда, в котором я работаю последние несколько лет, пусть вас это не смущает, сами принципы применимы и в других направлениях разработки.
Предположим, уже пару лет две питерские компании разрабатывают web-приложения для собственного бизнеса и сторонних заказчиков. В каждой компании работают четыре разработчика, по два в двух командах.
В первой компании, назову её Diversity, разработчики постоянно пробуют технологические новинки и любят поспорить друг с другом о преимуществах разных технологий. Одна команда пишет на TypeScript и использует React, вторая команда предпочитает JavaScript без типизации и использует Vue (подставьте здесь свои любимые технологии и фреймворки).
Во второй компании, пусть это будет Standard & Co, решили стандартизировать разработку и всё пишут на одном стеке с подробным регламентом разработки, пусть это будет React и Flow (типизированный JavaScript).
Давайте посмотрим, как эти компании будут справляться с традиционными задачами компании-разработчика web-приложений, и как стандартизация будет помогать (или мешать) их решению в Standard & Co.
Общие проблемы и общие решения
Стандартизация стека
Представьте, что обе компании решили внедрить в свои приложения календари с удобным выбором диапазона дат. Что произойдёт в этом случае?
Большая часть задач разработчика однотипны и уже имеют решения. Часто работа сводится к поиску готового решения в интернете и адаптации его под нужды конкретного проекта.
В примере с календарями разработчики сначала нагуглят готовые решения для своих фреймворков и выберут те, которые легче адаптировать под свои нужды. В Diversity разработчикам придётся проделать эту работу дважды, для первой команды и для второй, разные фреймворки не допускают общих решений. В Standard & Co эту работу можно поручить одной команде, вторая команда сможет быстро воспользоваться наработками первой.
Если речь идёт о разработке с нуля, Standard & Co сможет разделить работу между командами, в Diversity обеим командам придётся выполнить весь объём самостоятельно.
Руководители проектов каждой из команд обеих компаний пишут оптимистичные отчёты, разработка идёт своим чередом, разработчики выполняют свои задачи в нормальном режиме, но если посмотреть на эффективность компании в целом, то Standard & Co решила задачу с меньшими затратами ресурсов.
Отсюда мораль: единый стек — первый шаг к стандартизации разработки ПО.
Шаблон приложения
Бизнес Standard & Co развивается, компания постоянно создаёт новые приложения, поэтому разработчики решили создать для них общий шаблон, чтобы команды могли быстро стартовать и не терять время на разработку типичных архитектурных решений. В шаблон кроме самых базовых вещей решили включить модуль запросов к серверу, стандартизировали обработку ошибок, показ уведомлений, лоадеров, модальных окон и т.д. Обе команды создают стандартные части приложений одинаково, быстро и на автомате.
В Diversity команды каждый раз пробуют новые модули и решения независимо друг от друга, за обедом они увлечённо рассказывают друг другу о своих находках.
Standard & Co опять впереди с точки зрения общей производительности, они устранили расход времени на решение повторяющихся задач.
Мораль: стандартная архитектура экономит время.
Библиотека стандартных решений
Общая библиотека готовых решений (или даже не одна) рано или поздно появляется в каждой компании, которая создаёт ПО. Во фронтенде это библиотека компонентов интерфейса. Разработчики обычно ищут подходящее опенсорсное (или платное) решение или создают собственную библиотеку.
В Standard & Co взвесили за и против и решили сами создать одну общую библиотеку готовых компонентов (календари, поисковые строки с автодополнением и прочее) с прицелом на собственную дизайн-систему.
Diversity продолжает эксперименты с технологиями и даже может похвастать наличием нескольких библиотек в одном приложении. Под каждую отдельную задачу подбирается идеально подходящий модуль. Это интересная задача, но иногда такие модули требуют большого количества времени для интеграции.
Обе компании пришли к одному выводу: использование библиотек готовых решений высвобождает время разработчиков для реализации бизнес-логики, т.е. создания ценности для заказчика. Но в Standard & Co обнаружили ещё и некоторые дополнительные эффекты от использования общей библиотеки. Читайте далее!
Тестирование
Ещё один плюс, который обнаружила Standard & Co во время использования общих решений — это уменьшение количества ошибок в приложениях. Дело в том, что общие решения, которые используются в обеих командах, тестируются в разных сценариях, и с каждым новым приложением этих сценариев становится всё больше. Уверенность компании в надёжности общих решений и библиотек растёт со временем. Одна из аксиом тестирования — нет ПО без ошибок, поэтому увеличенный ресурс тестирования общих решений постоянно повышает качество конечного продукта.
Diversity подвергается большему риску, постоянно интегрируя новые решения. Ей приходится тратить значительные усилия для поддержания необходимого качества своих приложений.
Ротация проектов и людей
Ситуация на рынке изменилась, обеим компаниям пришлось на некоторое время приостановить разработку в одной из команд, тогда как другой команде наоборот, добавили работы и сократили сроки вывода продукта на рынок.
Standard & Co быстро усилила вторую команду разработчиками из первой, избежав простоя и поиска новых разработчиков. Переход на другой проект не занял много времени, разработчики снова погрузились в знакомую среду, им нужно было только разобраться с бизнес-логикой.
Так же легко Standard & Co решает и другие вопросы с перераспределением людей по проектам, будь то переходы из команды в команду из-за личных предпочтений или объединение команд.
В Diversity руководство встало перед сложным выбором: переучивать разработчиков первой команды на технологии второй, с чем, кстати, не все будут согласны, или открывать вакансии и набирать новых разработчиков. В любом случае потребуется дополнительное время для усиления второй команды, и может быть простой в работе первой.
Планирование
В Diversity уже накопили достаточный опыт планирования и понимают, какой запас времени необходимо заложить, чтобы учесть риски разработки.
В Standard & Co планирование имеет свои особенности. Благодаря большому количеству стандартных решений руководители проектов точно планируют время разработки, и в типовые проекты не закладывают дополнительные риски. Чтобы так делать, нужно заранее выяснить, какие части приложения потребуют нестандартных решений. Если разработка пойдёт не по плану, последствия могут быть серьёзными.
Рост компании
Маркетологи объявили следующий год годом расширения бизнеса в обеих компаниях. Пока точный объём работ не определён, но начать готовиться к росту нужно уже сейчас. Необходимо расширить разработку и нанять новых людей.
Standard & Co решает вопрос наймом начинающих разработчиков, которые могут обучаться и набираться опыта в любой из двух команд, и затем остаться в них или работать по общим стандартам как самостоятельные команды. Благодаря проведённой стандартизации возможны любые перестановки.
Diversity решает набрать новую команду, которая самостоятельно определит, с какими технологиями она будет работать, нужно быть в курсе технологических трендов. Вероятно, у них будет получаться лучше, чем у первых двух, но лучше подготовиться и к неожиданностям.
Контроль за разработкой и ревью кода
После появления новой команды, разработчики Standard & Co по очереди проводят ревью кода новичков, обучая их работе по стандартам компании и перенимая у них новые знания. Контролировать разработку в новом проекте может практически любой сотрудник компании с достаточным опытом разработки, там всё стандартно. Контроль и ревью требуют ресурсов, здесь Standard & Co снова имеют пространство для оптимизации.
В Diversity руководству приходится полагаться на лидов разработки. На эти позиции в компании попадают только зарекомендовавшие себя профессионалы. Компания полагается на честность и профессионализм этих ребят, ценит их вклад, постоянно заботится об их профессиональном развитии и высокой мотивации.
Эффективное общение
Программисты в Diversity любят спорить, о том, какая технология круче. Со стороны эти споры могут выглядеть, как битвы титанов. Матёрые разработчики кладут друг друга на лопатки очередным изящным выпадом в слабое место противника. Однако, пошумели и разошлись. Обычно такие баталии бывают эффектными, но не эффективными.
Разработчики Standard & Co после таких разговоров идут дорабатывать общий для них код. Помогая себе, разработчики помогают и другим, и наоборот. Ещё после недавнего набора новых разработчиков в Standard & Co проводят обучающие мероприятия. Раз в неделю кто-то из разработчиков разбирает технический вопрос из ежедневной практики, теперь можно с пользой для дела в рабочее время поговорить на общие темы.
Модернизация и быстрые технологические улучшения
Ещё одно преимущество стандартизации Standard & Co обнаружила после выхода новой версии языка TypeScript. Она показалась разработчикам удобнее для разработки, чем Flow, который они уже давно использовали. Разработчики Standard & Co переписали шаблон приложения и библиотеку компонентов интерфейса на TypeScript, сделав разработку проще, а код лаконичнее.
Сколько бы команд не было у компании, после обновления общих шаблонов и библиотек новый функционал сразу становится доступным для всех и проходят разностороннюю обкатку и тестирование. Инициатива о модернизации может исходить от любой из команд, за актуальностью стека в Standard & Co следит уже коллективный разум.
В Diversity каждой команде приходится самостоятельно следить за актуальностью своего стека и своевременно обновлять технологическую базу, что требует дополнительного времени и трудозатрат.
Негативные эффекты стандартизации
Потеря квалификации
Разработчики в Diversity — настоящие профи с широким кругозором и большим опытом в разных технологиях, а в Standard & Co много начинающих разработчиков и однотипных несложных задач, часто программистам становится скучно и хочется новых вызовов.
Если разработчик всё время выполняет стандартные рутинные операции, он может перестать развиваться и интересоваться технологиями. В таких условиях кто-то может даже перестать видеть свою ценность за пределами одной компании и постоянно терять мотивацию, и даже закончить тем, что вместо творческого труда будет просто ходить на работу за зарплату. Да и сама эта зарплата не будет высокой и не будет быстро расти, потому что система настроена на стандартизацию и упрощение работы каждого отдельного сотрудника и увеличение производительности системы в целом.
Стандартизация может негативно повлиять на уровень программистов.
В Standard & Co понимают эту проблему и стараются стимулировать творческую энергию своих разработчиков и направлять её на поиск более эффективных решений в собственном процессе разработки, углубление фундаментальных знаний, постоянную актуализацию стека и самообразование. Очень важно, что в Standard & Co направляют деньги и другие ресурсы как на технологическое развитие, так и на построение карьерного плана своих сотрудников.
Привязка к стеку
Бизнес-модель Diversity позволяет взять в разработку проект, часть которого уже готова или для которого заказчик определил стек технологий. Для этого ей нужно сформировать новую команду и наладить в ней процессы, что для Diversity совсем не сложно, учитывая её предыдущий опыт.
Руководство Standard & Co постарается договориться о переводе проекта на уже знакомые ей технологии. Если переговоры не приведут к желаемому результату, скорее всего компания откажется от проекта, новые для компании технологии — источник больших рисков.
Отклонения от стандартов — источник прогресса и ошибок
У новых разработчиков Standard & Co часто есть искушение вместо стандартного решения использовать какое-то другое, возможно более подходящее для конкретной задачи. В этом случае руководство компании предлагает тщательно взвесить все за и против.
Если новое решение окажется заметно лучше стандартного, то его нужно включить в стандарт и использовать во всех командах.
Если новое решение вместе с преимуществами также обладает и недостатками по сравнению со стандартом, или его преимущества невелики, такое решение не стоит использовать. Оно приведёт к дополнительным затратам времени на разработку, ревью, тестирование, обучение и прочее. Новым разработчикам придётся тратить больше времени на изучение технологий проекта.
Нестандартные решения могут содержать ошибки. Время, необходимое на исправление нестандартного кода обычно больше, чем время на доработки стандартного, уже знакомого кода.
В Standard & Co разработали специальные программы, которые мотивируют разработчиков с одной стороны придерживаться стандартов, с другой стороны постоянно их улучшать.
Стандартизация не происходит сама
Может показаться, что Standard & Co всё время экономит время и деньги благодаря стандартным решениям в разработке. Это так, но картина будет неполной, если не учесть издержки на сам процесс стандартизации.
Стандартизацию нужно направлять, кто-то должен разработать сами стандарты, написать регламенты, создать инфраструктуру, постоянно мотивировать коллег к пользованию стандартными решениями, контролировать их правильное понимание и применение. Для этого требуются время и усилия, которые Diversity может потратить на новый проект, обучение или улучшение условий труда.
Сами стандарты кто-то должен постоянно пересматривать и совершенствовать, иначе компанию ждёт технологический застой. Во фронтенде это особенно опасно, всего пара лет, и вы счастливый обладатель тяжёлого legacy, которое отнимает у компании ресурсы.
Два иероглифа в начале — кайдзен, японская философия постоянного совершенствования процессов производства, управления, бизнеса, жизни. Стандартизация — один из принципов этой философии. В середине прошлого века Toyota применяла принципы кайдзен, и в результате получила теперь уже знаменитую систему Канбан.
Стандартизация ускорила развитие промышленности, постепенно меняет и разработку ПО. Но здесь всё не так просто, человеческое мышление поменять сложнее, чем фрезерный станок.
