10 вещей о процессе разработки программного обеспечения для каждого CEO

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

Точка зрения каждого ограничена

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

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

Фичи не равны качеству

Сосредоточение внимания на количестве функций, а не на качестве основных — это бич многих разработчиков. Как переориентироваться на качество?

• Повысить удобство использования приложения для конечных пользователей. Не нужно перебирать десятки функций, которыми юзер никогда в жизни не воспользуется.
• Уменьшить вероятность непредвиденных ошибок и простоев
• Сделать обслуживание и техническое обслуживание намного проще для всех участников
• Обеспечить более продуманную разработку, основанную на мнении пользователей, в будущем.

Вы сэкономите довольно много денег, так как вам не придется тратить их на ненужные компоненты, рефакторинг, обслуживание и даже место на сервере. Поэтому, если ваши разработчики, UX-дизайнер или владелец продукта предполагают, что ваш бюджет лучше потратить на оттачивание и надлежащее тестирование минимально жизнеспособного продукта (MVP), пожалуйста, примите во внимание их слова.

Задействовано больше людей, чем вы думаете

Можно смело предположить, что вы генеральный директор и/или бизнесмен, и именно на этом вы хотите сосредоточиться – на развитии своего бизнеса. По крайней мере, вряд ли вы хотите стоять над душой разработчика и смотреть, как он медленно и вдумчиво пишет код. Вот почему хорошая, разносторонняя команда, которая позаботится обо всем процессе разработки программного обеспечения вместо вас, — это лучшее, что может случиться. Допустим, вы хотите создать приложение для iPhone. Скорее всего, вам понадобится один дизайнер для создания UI и UX для вашего приложения и два инженера. Один iOS-инженер и один backend-инженер. Точно так же, как нет музыканта, который одинаково хорошо играет на фортепиано, скрипке и гитаре, разработчики программного обеспечения, как правило, специализируются в определенной нише и должны сотрудничать для создания продукта. Добавьте к этому скрам-мастера и бизнес-аналитика, и вдруг окажется, что довольно много людей заинтересованы в том, чтобы сделать ваш проект потрясающим.

Стоит ли оно того? Есть плюсы и минусы, как и во всем. Но самое главное — эти люди должны быть вам полезны, тогда вложение средств оправдает себя.

Процессы требуют времени

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

Обычно проектом среднего размера занимаются 5-7 человек, и все, что им нужно сделать, это скоординировать друг с другом и поменять местами части работы, ну и добавить свои собственные, чтобы кто-то другой протестировал получившийся код. Чем больше вы масштабируете, тем больше времени требуется на координацию и разработку, поскольку число различных зависимостей растет как в процессе разработки, так и в плане кода. Настоятельно рекомендуется учитывать это при планировании бюджета и маркетинга — бизнес-аналитик со стороны производителя программного обеспечения обычно может помочь получить представление об этом.

Вы получаете то, за что платите (в сроки, которые вы даете)

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

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

Вся информация имеет значение

В разработке программного обеспечения не бывает слишком много информации. Чем больше команда разработчиков знает о вашем подходе, планах на будущее и текущих событиях, тем лучше получится спланировать и подготовиться ко всему, что вы можете им предложить в будущем. Один раз, когда они не узнают о вашем затянувшемся отпуске, может привести к тому, что важное решение не будет принято. Неправильное информирование об изменении плана может привести к разработке совершенно ненужных функций, которые раньше были необходимы.

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

Разработчики предполагают, что вы что-то знаете

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

А что вам точно нужно знать о разработке? Знайте свой программный стек. Что такое программный стек? По сути, это список всех технологий: фреймворков, языков программирования, сервисов, которые использует ваша команда разработчиков. Если вы используете Rails для своего бэкэнда, вы не можете просто нанять Java-инженера и ожидать, что он все сделает так, как вы рассчитываете. Вам также потребуется знать технические термины: бэкенд, интерфейс, адаптивный дизайн, баги. Потому что ваш разработчик будет их использовать, и вы должны быть на одной волне.

Идеального плана не бывает

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

Это может быть что угодно: разработка функции занимает больше времени, чем предполагалось, кто-то из ваших стейкхолдеров настаивает на досрочном выпуске (из-за маркетинга), или даже тот факт, что ребенок технического руководителя заболел и ваш СТО вынужденно ложится с ним в больницу. Сегодняшний Agile-подход к разработке программного обеспечения является огромным подспорьем в этом отношении. И до тех пор, пока коммуникация внутри и вокруг проекта протекает эффективно, эти коллективные усилия, направленные на то, чтобы говорить, слушать и адаптироваться, должны быть в центре внимания процесса разработки.

Разные разработчики говорят на разных диалектах

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

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

Разработка не заканчивается релизом

Ваше приложение запущено, все в восторге. Но действительно ли с программным обеспечением покончено? В 99% случаев ответ будет «нет». Требуется техническое обслуживание, ваши пользователи, вероятно, выскажутся с пожеланиями об улучшениях и новых функциях, даже требования к системе и браузеру рано или поздно потребуют некоторой доработки. Вот почему всегда полезно мыслить долгосрочными категориями — кто позаботится об этих вещах? Есть ли у вас команда DevOps, которая решает самые насущные вопросы? Кто будет отвечать за развитие приложения? Эти вопросы ведут к финансовым и функциональным решениям, которые лучше обсудить как можно скорее. Даже если ваша текущая команда не обеспечивает поддержку после релиза, им было бы полезно знать, как все подготовить для своих преемников.

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