Этапы разработки ПО. Как их видит разработчик и заказчик
Есть много статей повествующих о каскадной, итеративной и других всеми любимых моделях разработки. Каждая из этих статей рассказывает о преимуществах и недостатках и предлагает читателю самому сделать правильный выбор в зависимости от проекта. Смешно то, что человеку, который будет принимать решение о модели и этапах разработки, скорее всего не нужно читать об этом статьи. Он и так все знает. С другой стороны “целевая аудитория” таких материалов сможет применить эти знания только через время (и то если сильно повезет). Поэтому предлагаю читателю прочитать не теорию из учебников, а послушать про реализацию на практике. Мы разберем про различия в подходах аутсорсинговых и продуктовых компаний. И чем различается взгляд на модель разработки с точки зрения заказчиков(работодателей) и разработчиков(сотрудников).
Джун на аутсорсе
Начнем наше повествования от лица начинающего разработчика, которому удалось пройти свое первое интервью и устроиться в аутсорсинговую компанию. Почему именно джун и именно аутсорс ? Потому что, с одной стороны, 90% всех компаний – это аутсорс, а с другой модель разработки обычно изучают в универе, либо на “ранних этапах становления” и автор статьи очень надеется охватить большинство.
Итак, вы устроились в компанию и после небольшого инструктажа и знакомства с командой, получаете свою первую задачу. Какая у вас первая мысль ? Верно ! Написать свою функцию сортировки, кое-как на коленке выполнить задачу, чтобы она у вас работала и с чувством гордости смержить ваш код в мастер ветку, дабы показать что вы не просто так получаете зарплату. Назовем это этапом Разработки.
И если компания, в которой вы работаете очень маленькая, то возможно вам даже удастся такое провернуть. Просто потому что у некоторых начинающим ООО или ИП просто нет возможности нанять команду сеньеров и они считают, раз закончил институт, значит программист, а если программист, то иди и программируй мне. И чтобы все работало. Таким образом в вашей команде разработки совсем не обязательно будут опытные коллеги, которые смогут поправить вас. К тому же ревью кода отнимает время как минимум 2-x разработчиков и работодателям не всегда понятно зачем менять уже работающий код, а значит даже в опытной команде совсем не обязательно что вам будут указывать на ваши ошибки.
Но этап Ревью нужен. Представим, что вам все таки попалась жизнеспособная компания, которая понимает важность соблюдения определенных правил разработки, поэтому после того как вы закончили свою задачу, создается merge request и ваш наставник начинает разбираться в том что вы натворили.
Скорее всего ваше первое ревью будет долгим, т.к вам потребуется не только исправить не только архитектурные и логические ошибки в вашем коде, но также и соблюсти code style (свод правил написания кода, специфичный для конкретной компании). Здесь самое главное чтобы ваш ревьювер не сильно увлёкся. У ревью можно выделить 2 главных назначения:
Первое. Убедиться, что ты написал код, который будет работать всегда. Здесь мы предполагаем, что разработчик уже убедился в работоспособности кода (иначе какой смысл отдавать не работающий код на ревью). При этом можно упустить частные случаи, о которых начинающий девелопер может просто не знать.
Второе. Привести ваш код к некоторому стандартному виду. Чтобы в нем соблюдались правила и структура существующего приложения. Грубо говоря, нужно сделать ваш код внешне похожим, на уже присутствующий в проекте.
При этом очень важно сильно НЕ ударяться в перфекционизм. НЕ нужно по несколько дней вылизывать ваш код. Здесь нужно помнить о правиле “Лучшее враг хорошего”.
После того как вы закончили с ревью и ваш код оказался в общем репозитории наступает следующий этап – Тестирование.
Как правило аутсорсинговые компании имеют отдельных тестировщиков. Это люди, которые не занимаются разработкой, а пытаются сломать вашу новую фичу, после чего приходят и говорят “чини”. И это хорошо, что есть такие люди. Т.к даже будучи разработчиком сложно найти уязвимости в своем коде. Отчасти потому что ты из всех сил пытаешься их не искать и не ломать код. Но даже если честно взглянуть на свой код, то очень сложно учесть все варианты взаимодействия пользователя (а их очень много).
Тем не менее отдельные люди, занимающиеся тестированием – это совсем не обязательное условие. Особенно в небольших стартапах, у которых просто нет на это бюджета. И поэтому в таких командах тестированием кода занимаются сами разработчики. При этом бывает тестирование 1-й конкретной фичи, которую ты только что добавил, а бывает тестирование новой версии вашего приложения. И во втором случае могут быть задействованы ни один, а целая команда разработчиков.
Про автоматические тесты
Я не стал включать в главу про тестирование написание автоматических unit и интеграционных тестов. Поскольку считаю, что тесты - это не механизм проверки работоспособности вашего кода. Да конечно, есть TDD – но опять же, в этом случае вы с помощью тестов просто запускаете ваш код. Поэтому написание тестов нужно относить к этапу разработки.
Автоматические тесты – это в первую очередь защита от регрессии (поломки вашего кода) в будущем, т.к в момент написание тестов они точно будут работать (а тесты имеют смысл, только когда они перестают это делать).
Разработка, ревью, тестирование
Это 3 этапа которые повторяются для каждой новой задачи в процессе разработки. И это то, чем вы будете ограничены, когда устроитесь на свою первую работу.
При этом каждая задача зачем-то и как-то появляется. И точно также после реализации нового функционала, есть какой-то выхлоп. Поэтому теперь давайте взглянем на этапы создания приложения, которые только косвенно относятся к разработке.
От разработчика к менеджеру
Как правило, начинающие и разработчики среднего уровня не взаимодействуют напрямую с заказчиком, (но могут с командой разработки со стороны заказчика). Менеджерские функции выполняют Team-лиды, Product и Project менеджеры. Давайте рассмотрим чем отличаются эти 3 категории и чем они занимаются.
Team Lead, Product и Project менеджер
По большому счету люди на этих постах выполняют одинаковую задачу. Они ставят задачи своим подчиненным и контролируют исполнение этих задач. При этом руководитель каждого типа должен уметь решать задачи, которые он сам ставит, чтобы в случае чего решить проблему самолично.
Отличие этих руководящих должностей в том, кто находится у них в подчинении. Схема следующая:
Product Manager -> Project manager -> Team Lead -> Разработчик
Естественно нужно понимать, что чем более “менеджерская” твоя должность тем более высокоуровневые задачи ты ставишь перед своими подчиненными.
Также, если вы захотите детальнее узнать про отличие этих должностей, то вероятно найдете, что-то из разряда Product менеджер решает ЧТО нужно разрабатывать, а Project менеджер КАК это разрабатывать. Но по большому счету это не является отличием, т.к в сухом остатке каждый получает некоторую задачу, которую он должен как то сделать. И само собой в ходе реализации будут заданы вопросы ЧТО, КАК и много других. Только заданы они будут к подзадачам, на которые разбивается исходная.
Какие задачи решают менеджеры
В качестве примера рассмотрим Team-лида, т.к почти каждая IT компания имеет в своем арсенале таких людей. Product и Project менеджеры все таки более редкие персонажи.
Итак, вам написал заказчик с просьбой разработать ему приложение. Разбирать как он вас нашел мы не будем, т.к это тема для отдельной книги. Просто будем считать, что почему-то он выбрал именно вашу фирму.
Первый этап – это обсуждение требований. Здесь вы выслушиваете хотелки клиента и с умным видом качаете головой, параллельно думая как можно реализовать тот или иной функционал. В ходе этого этапа вы должны определиться с “границами” в рамках которых ваша команда будет создавать новый проект. Какие технологии нужно использовать в разработке. Как будет отслеживаться прогресс. Список задач, которые нужно реализовать. Временные рамки. Первый контакт с заказчиком как правило происходит через письменные методы связи (мессенджеры, почта)
Далее вы анализируете поставленные требования на предмет выполнимости. Анализ проходит совестно с разработчиками, т.к хоть разработать можно практически всё (вопрос лишь во времени), но временами возникают проблемы с тем как заказчик потребовал вести эту самую разработку. К примеру, требуется разработать видео-сервис, который будет размещен на хостинге существующего сайта заказчика. Однако в силу того, что для этих целей потребуется больше вычислительных мощностей, то интеграция с существующим хостингом скорее всего будет невозможна.
После анализа вы вновь встречаетесь с заказчиком и совместно корректируете требования. Эта часть, как правило, занимает больше времени, а значит может проходить в формате видео-встречи.
После того как вы определились с финальными требованиями нужно оценить проект. Для этого весь проект делится на отдельные задачи, где каждой задаче ставится некоторая оценка по времени. При этом нужно понимать, что это должна быть верхне-уровневая оценка, поскольку заказчику не очень интересны детали разработки. Ему лишь нужно знать, что на его 10 страничный сайт уйдет 10 недель и каждую новую неделю он сможет взглянуть на еще одну страницу.
Также в рамках оценки проекта составляется команда, которая будет его реализовывать. При чем необязательно определится с конкретными людьми. Нужно лишь составить список из ролей. К примеру, 2 мидл разработчика, 1 старший, Тестировщик, Дизайнер и Team Lead. Естественно обговаривается сколько рабочих часов будет тратить каждый из специалистов и сколько стоит этот час. К примеру дизайнеры и тестировщики могут одновременно работать над несколькими проектами, а значит их вклад в текущий может быть только частичным (4 часа в день вместо 8).
Третий этап – распределение задач внутри команды. Здесь нужно отметить, что не всегда эта команда есть в наличии. Поэтому заказчику могут сообщить, что требуется время на донабор сотрудников. Но так или иначе это время естественно не оплачивается, это лишь означает, что будет задержка с тем, когда будет закончен проект.
В ходе распределения задач оценивается сложность каждой задачи, после чего эта задача попадает в Backlog (это список всех задач текущего проекта). Нужен он потому что нельзя сразу распределить задачи по разработчикам. Как правило, все IT компании работают по методологии Scrum или Agile.
В случае со Scrum каждые 2 недели(Спринт), из бэклога достается небольшой скоуп задач, которые распределяются между разработчиками. При этом если некоторые задачи не удается выполнить в текущем спринте, то они переносятся на следующий.
В случае с Agile, нет дробления на спринты. Разработчики берут задачи по мере выполнения. При этом нужно сказать, что почти во всех командах, есть некоторые промежуточные этапы в ходе которых анализируется сколько уже было сделано и сколько осталось.
После разработки начинается период поддержки готового продукта. Здесь нужно отметить, что, как правило, этим занимаются продуктовые компании, а вот аутсорсинговые, если и предлагают услуги поддержки после разработки, то эта поддержка длится небольшой срок. А если заказчику требуется постоянное сопровождение, то это уже отдельная услуга.
Тем не менее, большая часть проблем должна решаться после разработки, но до того как заказчик принимает работу. Зачастую в команде заказчика могут собственные тестировщики, задача которых финальная проверка готового приложения.
А что же в Продуктовых компаниях
В любой продуктовой компании сильно повышается роль сопровождения написанного кода, поскольку разработчики понимают, что он (код) с ними надолго, если не навсегда. Поэтому в таких компаниях намного жестче относятся к написанию автоматических тестов, проведению ревью и культуре кода.
Здесь нужно заметить, что есть чисто продуктовые компании, а есть те у которых, кроме разработки собственного приложения, есть еще и заказчики. Таким образом они являются чем-то средним среди этих двух групп. А если сказать точнее к ним относятся характеристики от обеих.
Работая в продуктовой компании у вас появятся моменты “Релизов” (когда выходит новая версия продукта). Такие релизы могут проходить раз в несколько месяцев или даже лет. Это время, когда проходит контрольное тестирование новой версии продукта, находится и исправляется большое число багов. Вы можете фиксить неисправности по несколько дней или недель (в зависимости от размера обновления). В какой-то степени - это можно сравнить с завершением проекта при работе с заказчиком (только ответственность за тестирование лежит полностью на вас).
В продуктовых компаниях сильно поднимается значимость Product и Project менеджеров, т.к любой продукт испытывает конкуренцию на рынке и нужно предпринимать решения, которые помогут выиграть в этой борьбе. Нужно выбирать вектор развития. Решать какой функционал необходим здесь и сейчас, а какой может подождать. Иногда закрывать неудавшиеся направления. То есть по большому счету быть предпринимателем (работающим по найму).
И последнее отличие продукта от аутсорса – это наличие технической поддержки. При этом, это не сами разработчики, а отдельные люди(команды), которые занимаются запросами клиентов и пользователей. Конечно, тех. поддержка часто может получать сообщения о багах, после чего просто перенаправлять их разработчикам, но их главная задача фильтровать огромное число обращений и передавать, только самые сложные. А это значит, что специалисты тех. поддержки также должны отчасти разбираться в коде. Чтобы иметь возможность отвечать на базовые вопросы.
Взгляд с позиции заказчика
А теперь давайте посмотрим на процесс разработки софта с позиции заказчика. Заказчиком может выступать предприниматель у которого есть некоторая идея приложения и ему нужна команда, которая реализует эту идею. В этом случае взаимодействие с этим клиентом скорее всего будет происходить напрямую. Все требования выбудете получать от него и отчитываться о статусе вы также будете ему.
В случае, когда ваши услуги заказывает большая компания, то скорее всего взаимодействовать вы будете с такими же менеджерами, которым поручили проследить выполнение проекта.
Итак, представим себя на месте одного из таких менеджеров. Вы внутри своей компании долго разрабатывали план выхода на новый рынок и пришли к тому что вам необходимо автоматизировать некоторые процессы и увеличить свою производительность. У вас нет собственной команды разработки, т.к содержать ее постоянно слишком дорого. Поэтому вы пользуетесь услугами Аутсорсинговых компаний.
Первое, что вам нужно сделать – это найти такую компанию. Поскольку их количество на рынке просто зашкаливает, то чтобы выбрать правильную вам необходимо немного погрузится в разработку (как минимум на том уровне чтобы понять как лучше реализовать ваш проект, а самое главное почему). Постучитесь в несколько компаний и выясните как бы они стали реализовывать ваш проект, узнайте почему они используют именно эти технологии и процессы. После чего сами узнайте о том что вам предлагают, сделайте вывод что подойдет именно вам и уже начинайте искать целенаправленно. Самая дорогая компания совсем не обязательно даст вам лучший результат. Просто потому что большие компании тратят деньги не только на зарплату разработчиков, дизайнеров или др. сотрудников “создающих продукт”. Но также и на менеджмент и обслуживающий персонал (HR), а значит они должны закладывать это в цену. При этом сотрудников они набирают на одинаковых сайтах.
Второй этап – это правильно объяснить что вы хотите. Здесь самое важное изначально учесть максимально все детали, которые вам будут необходимы в будущем приложении. Любое дополнение, которое вы захотите сделать в середине разработки будет в среднем сложнее(дольше) реализовать, чем если об этом требовании было бы известно заранее.
Наверняка вы хотите отслеживать процесс разработки, поэтому договоритесь с вашим исполнителем о датах, когда вам будет показан прогресс. Это поможет не только держать руку на пульсе, но и внести коррективы на раннем этапе, в случае если это необходимо. Это также полезно, поскольку у вас тоже могут быть люди, перед которыми вы отвечаете. Будь то инвесторы или высшее руководство.
По возможности посвятите команду разработки в контекст задачи, чтобы вы понимали друг друга и общались на одном языке. Поскольку зачастую бывает такое, что программисты знают как написать программу, но не понимают для чего нужна та или иная функция. И наоборот заказчик понимает что он хочет получить в итоге, но не мыслит как разработчик, а потому ему сложно грамотно поставить задачу.
Когда разработчики знают, как будет использоваться в дальнейшем их приложение они реализуют функционал таким образом, чтобы он работал наиболее эффективно именно для вас.