Connect with us

Разработка

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

Этой статьей мы открываем серию публикаций, посвященную одной из самых флеймообразующих тем разработки – управлению разработкой. Зачем мы это делаем? Потому, что это интересно.

Григорий Петров

Опубликовано

/

     
     

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

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

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

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

1

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

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

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

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

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

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

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

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

2

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

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

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

Заключение

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

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.