Григорий Петров: Управление разработкой. Специфика разработки

Приветствую, коллеги. Этой статьей мы с AppTractor открываем серию публикаций, посвященную одной из самых флеймообразующих тем разработки — управлению разработкой. Зачем мы это делаем? Потому, что это интересно. Потому, что об этом мало пишут (как это ни странно). Потому, что огромное количество проектов проваливается не из-за неправильного выбора фреймворка или неурочного пивота, а из-за потери контроля над разработкой. Колонка авторская, вести ее буду я, поэтому давайте познакомимся.

Меня зовут Григорий, уже больше 15 лет я занимаюсь разработкой программ — пишу их сам, руковожу разработкой, консультирую разработку, провожу хакатоны, семинары, тренинги — в общем, активнейшим образом участвую. Последние несколько лет кроме больших проектов я в свободное время консультирую компании, как организовать разработку наименее болезненным способом и что делать, когда все плохо. За это время накопилось много интересных кейсов, опираясь на которые я могу сформулировать много проблем, свойственных именно разработке софта, и рассказать о возможных путях их решений.

Для кого мы это пишем? В первую очередь для разработчиков, и всех, кто с ними работает — менеджеров, заказчиков и просто сочувствующих. Поэтому публикации будут щедро разбавлены англицизмами и жаргонизмами, которые позволят мне сэкономить много-много букв и донести сложные мысли в компактной и простой форме. Если все пойдет удачно и вам понравится эта колонка, то мы надеемся сделать ее интерактивной — пишите нам о наболевшем, задавайте вопросы — а мы постараемся рассказывать об интересующих вас вещах и разбирать конкретные примеры. Ну и последнее, о чем стоит предупредить — все, что вы прочтете на этих страницах, является моим личным мнением и может не соответствовать объективной реальности, законам природы и здравому смыслу. Да поможет вам здоровый скептицизм.

Проклятье нулевой цены копирования

Разработка программ как массовая индустрия — штука относительно новая и безотносительно необычная. В этой публикации я хочу поговорить об особенности, которая, на мой взгляд, порождает множество проблем в нашей отрасли и о которой говорят очень мало. Видимо, считая «очевидной». Это особенность — нулевая цена копирования. Что это значит?

Когда строитель строит дом, то он, упрощенно, вначале разрабатывает проект дома, а затем строит первый дом. Поплакав над получившимся, он вносит в проект коррективы, строит второй дом, опять корректирует план и так далее. В результате с каждым новым построенным домом он строит все лучше, накапливает опыт и знания, учится на ошибках. При этом он может строить один и тот же дом с небольшими изменениями.

С программами все не так — после того, как программа написана, она может быть мгновенно размножена и передана любому количеству пользователей — у нее, как у книг, фильмов или музыки, нулевая цена копирования. Если разработчик написал программу, то в подавляющем большинстве случаев ему нет абсолютно никакой необходимости создавать точно такую же программу повторно. Конечно, есть исключения — к примеру, клепание под копирку однотипных лендингов или бизнес-автоматизации — но таких случаев меньшинство, да и технологии имеют обыкновение меняться, заставляя постоянно адаптироваться.

Нулевая цена копирования имеет ряд неприятных для нашей индустрии последствий. В этой публикации я хочу выделить две:

• В большинстве случаев программист разрабатывает новое. Для большинства программистов каждый следующий проект — это множество задач, которые нужно делать «первый раз в жизни». Новые платформы, фреймворки, алгоритмы, задачи, предметная область, инструменты и процессы. Как любят шутить айтишники, «рецепты успешных проектов — это кулинарная книга случайно получившихся блюд, ингредиенты которых существовали в единственном экземпляре».
• Накопление знаний идет очень медленно. Из-за того, что каждый последующий проект сильно отличается от предыдущего, значительная часть полученного опыта не может быть использована повторно в следующем проекте. Безусловно, некие общие знания накапливаются, наработки для одного комплекта технологий адаптируются при переходе на другой — но, по моему опыту, это происходит намного медленнее, чем в других областях человеческой деятельности.

И как с этим жить?

Нулевая цена копирования — штука с точки зрения организации работ не очень приятная, но и не сверхъестественная. Когда каждый следующий проект несет нам новое и интересное, самое простое управленческое решение — это в самом начале выделить незнакомую для нас область, которая способна принести наибольшее количество сюрпризов. На практике при старте нового проекта команда обычно разбивает его на крупные задачи и затем оценивает, насколько каждая задача новая. После чего для тех задач, которые команда делает впервые, делается минимальное исследование, способное выявить самые очевидные проблемы и проверить, правильно ли разработчики эти новые для них технологии понимают.

Пример из жизни

Команда разрабатывала решение, технически выполненное в виде расширения Google Chrome, которое регулярно проводило некие сложные действия над рядом страниц, в автоматическом режиме. По задумке авторов, браузер с расширением должен был быть включен постоянно, обеспечивая нужное пользователям поведение. Команда имела опыт веб-разработки, но с расширениями для Google Chrome сталкивалось впервые. Это их не смутило, и работа закипела.

Все шло хорошо, пока через месяц браузер с работающим расширением не оставили на выходные. Какового же было удивление ребят, когда в понедельник они обнаружили упавший Google Chrome. Эксперименты показали, что казавшаяся им стабильной платформа на самом деле просто не предназначена для таких задач, и десятки тысяч действий, которое расширение проводило над страницами, рано или поздно приводили к падению браузера. Специалист по тестированию, знакомый с selenium и веб-драйверами, сказал бы что это очевидная вещь. Но нюанс состоит в том, что команда занялась автоматизацией браузера в первый раз, и им просто неоткуда было знать такие нюансы.

Что можно было сделать? Перед началом работ выделить «написание расширений для Chrome» как неизвестную область и написать минимальный прототип, работающий с десятком страниц. Упавший через некоторое время браузер сразу показал бы команде, что выбранный стек технологий не совсем подходит для решаемой задачи, и они сэкономили бы много времени.

Заключение

Ваши комментарии и пожелания приветствуются — мы надеемся, что эта новая колонка будет не только интересным чтивом, но и принесет немного добра и пользы в иногда слишком интересную жизнь разработчика.