Текст книги "IT-рекрутмент. Как найти лучших специалистов, когда все вокруг горит"

Глава 7
Этапы разработки ПО

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

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

В финале вы тестируете все внутренние системы дома, чтобы они работали исправно. Принимаете помещение, документируете всё, что в нем есть, и подписываете акт приемки.

И наконец, происходит внедрение нового продукта в вашу жизнь: в случае с домом вы въезжаете в него, осваиваетесь в новом пространстве и начинаете там счастливо жить.

Разработка ПО происходит по тому же принципу: от проектирования через создание к внедрению и сопровождению. Давайте детально рассмотрим все этапы, которые возникают на каждой ступени развития событий.

1-й этап. Подготовка: сбор и анализ требований. Чтобы понять, какое ПО нам нужно получить в результате, на первой стадии его необходимо детально описать, а также спланировать этапы работ, сроки, ресурсы и стоимость.

Сбор и обработка требований бывает двух типов: внутренняя – для разработки продукта, который та или иная IT-компания собирается самостоятельно выпустить на рынок, или внешняя – когда IT-компания принимает заказ от сторонней организации, которой требуется какой-то программный продукт.

Какие специалисты будут участвовать в работе на этом этапе?

● Product-/Project-менеджеры, как говорилось выше, это специалисты, которые отвечают за административную часть. Повторюсь: проджект-менеджер отвечает за успешное выполнение проекта в установленные сроки и бюджет, а продакт-менеджер – за продукт в целом, от идеи до потенциального развития после выхода. Подробнее о том, как именно осуществляется управление проектом и кто еще будет в нем задействован, мы поговорим в отдельной главе.

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

● Аккаунт-менеджер подключается в том случае, если разработка заказная. Он осуществляет общение с клиентом и зачастую выступает своеобразным «переводчиком» между заказчиком и исполнителем.

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

Кроме того, на данном этапе выбирается методология разработки: каскадная (Waterfall) или Agile (Scrum, Kanban). О том, что это такое, мы также поговорим чуть позже.

3-й этап. Создание продукта. Этот этап, в свою очередь, включает в себя несколько частей: непосредственно разработка, тестирование, поддержка, доработка.

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

Разработка продукта, в зависимости от требований, может происходить с помощью следующих специалистов:

● Full-stack-разработчик – это специалист, который разрабатывает и интерфейсы, и внутреннюю логику продукта. Интерфейс – это, грубо говоря, то, что видит пользователь: например, заходя на веб-сайт, мы будем наблюдать разнообразные элементы, которые реагируют на нажатие, или просто мигают, или выскакивают нам навстречу в неожиданный момент. Внутренняя же логика – это код, который скрывается за этим фасадом и обеспечивает внутреннюю работу всей системы: пользователь эту «подводную утробу парохода» не видит. Например, нажав на эту или иную кнопку, мы видим всплывающую форму, но не видим, как это произошло: как система обратилась к базе данных, нашла нужную информацию и показала ее нам. Чаще всего фронтендом и бэкендом занимаются разные люди, но случается и так, что один или несколько универсальных специалистов делают всё.

● Frontend-разработчики – специалисты, которые создают клиентскую часть продукта, то есть то, что мы, пользователи, видим на веб-странице или в приложении.

● Backend-разработчики, соответственно, работают только над внутренней логикой.

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

4-й этап. Тестирование – как и следует из названия, на этом этапе проводится детальная проверка системы на работоспособность и соответствие всем предъявляемым требованиям. Оно может быть ручным или автоматизированным, и в обоих случаях в нем принимают участие тестировщики. (О них мы поговорим в отдельной главе.)

5-й этап. Внедрение. Казалось бы, на этом этапе все должно быть просто: ПО готово – внедряем! Однако этот этап включает в себя несколько нюансов, и в некоторых компаниях для его прохождения даже существуют отдельные специалисты. Например, если софт создан по заказу какой-то компании, которая собирается им пользоваться, то специалисты по внедрению должны интегрировать новое ПО в уже существующую систему и обучить пользователей.

Обычно процесс внедрения происходит следующим образом:

1. Документирование информации о софте – написание инструкций, которые помогут пользователям и другим разработчикам эффективно общаться с этой новой «сущностью».

2. Непосредственно внедрение системы: та самая интеграция нового ПО в уже существующее.

3. Анализ состояния ПО в новой инфраструктуре: вдруг что-то работает не так, как задумано.

4. Если ошибки выявлены, то специалист по внедрению привлекает разработчиков, чтобы те всё исправили.

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

Внедрение нового ПО – важнейший и во многом стрессовый этап для пользователей. Без грамотного проводника в новые возможности софта такое обновление может стать шок-контентом для всех сотрудников компании. Просто представьте: к вам приходит некто, сообщает, что теперь вместо 1С у вас установлен, скажем, 2С, который вы никогда в глаза не видели, – и гордо удаляется. Ситуация жуткая! На этом этапе пользователям необходима грамотная помощь и регулярное взаимодействие со специалистом.

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

● Первая линия (или HelpDesk) – решают самые простые задачи пользователей: выключите и включите компьютер – заработало? Поздравляю!

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

● Третья линия – специалисты, решающие сервисные вопросы. Они могут поправить ошибку в коде.

Команда технической поддержки может быть общей или специально выделенной под заказчика (в некоторых случаях специалисты могут даже постоянно работать на территории клиента).

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

Глава 8
Методологии разработки в IT

Работая в сфере IT, невозможно не столкнуться с терминами типа Scrum (скрам) и Agile (аджайл/эджайл). Но именно из-за того, что они постоянно на слуху и вроде бы все знают, что это такое, появляется масса недопониманий. Как говорил Марк Твен, «все проблемы не от незнания, а от уверенности в собственном знании». И к пониманию Agile в среде HR-специалистов это относится в полной мере.

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

И начнем мы, вопреки ожиданиям, с описания «негибкой» системы разработки: как строился процесс создания ПО еще несколько лет назад? С чего, как говорится, все начиналось?

Waterfall, или «Водопад», – традиционный подход к работе над ПО. Для него характерна последовательная разработка: первый этап, второй, третий и т. д. Каждый следующий начинается только после того, как закончился предыдущий.

Преимущество «Водопада» заключается в том, что мы можем более-менее точно рассчитать стоимость разработки и сроки ее завершения.

Основной же минус – при долгосрочном планировании мы рискуем получить на выходе технически и морально устаревший продукт.

Вот как схематически выглядит Waterfall-методология разработки:

В стародавние времена, когда производственные и бизнес-модели не менялись годами, каскадная разработка была вполне оправданна. Сегодня же бизнес не может отдать в разработку глобальную задачу и вернуться за результатом, скажем, через полгода. За это время бизнес-идея может потерять свою актуальность, технологии – измениться, кризис – грянуть (привет, ковид!), биткоин – упасть. Поэтому на смену «Водопаду» пришли так называемые гибкие методологии.

Они позволяют на лету менять требования к продукту, добавлять новые модули и отказываться от ненужных. У каждого типа методологий есть свои особенности, но объединяет их одно: наличие некоторых непродолжительных циклов, где результат предыдущего цикла (итерации) оказывает влияние на планирование следующего.

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

В 2001 году 17 представителей различных концепций разработки программного обеспечения собрались на горнолыжном курорте в штате Юта и составили Agile-манифест. Этот документ закрепил основные принципы и ценности гибкой разработки. На http://agilemanifesto.org/ его можно прочитать более чем на 50 языках, а также ознакомиться со списком авторов, которые его составили. На русском манифест выглядит следующим образом:

«Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

● Люди и взаимодействие важнее процессов и инструментов.

● Работающий продукт важнее исчерпывающей документации.

● Сотрудничество с заказчиком важнее согласования условия контракта.

● Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева».

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

Каковы же недостатки? Главный из них заключается в том, что разработка может вестись бесконечно. И от этого может быть больно в прямом и переносном смысле: сотрудники находятся в состоянии постоянного тонуса. Требуется скорость в принятии решений и реализации задуманного, но конечного результата не предвидится. Хотя важно признать, что большинство современных компаний все-таки стремятся к внедрению гибких методологий, ведь они больше отвечают реалиям современного мира.

Как выглядит Agile:

Гибкие методологии требуют развития soft skills у IT-специалистов. Если при каскадной разработке программист имел возможность длительное время работать в одиночку и никто его не трогал, то в условиях аджайла с регулярными планерами, демо и код-ревью ему необходим навык эффективного общения и работы в команде.

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

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

В семейство Agile входят следующие методологии: Scrum (скрам), Kanban (канбан), XP, Scrumban (скрамбан). Каждая из них имеет некоторые особенности, которые важно знать, если вы нанимаете персонал под проект.

Scrum – гибкая структура процессов для небольших команд (обычно до 10 человек), которые разбивают свою работу на промежуточные цели. Эти цели выполняются в рамках временных итераций (спринтов) продолжительностью от одной до трех недель, стандартный спринт идет две недели. В качестве подготовки к нему сперва выбирается список задач из бэклога – своеобразного журнала проекта, в котором указываются задачи по приоритетам и отмечается этап их выполнения.

Команда разработки проводит ежедневные 5–20-минутные митинги (совещания), которые позволяют отслеживать ход проекта, быстро выявлять возникающие проблемы и оперативно на них реагировать.

Kanban – еще одна гибкая методология. Основные принципы канбан были унаследованы от подхода, разработанного на заводе Toyota в 1950-х годах. Особенности этой методики заключаются в том, что разработка визуализирована: разделена на задачи, этапы их выполнения маркируются специальными отметками. Количество работ, производящихся одновременно, ограничено. Измеряется и оптимизируется время на выполнение одной задачи.

Extreme Programming, XP. Если описанные выше методологии применимы не только в разработке ПО, то XP – это подход, созданный специально для IT-бизнеса. Его идея проста: взять лучшие практики из других гибких подходов и довести их до экстремально высокого уровня. Например, в рамках данной методологии используется парное программирование: два разработчика на одной машине пишут одну фичу и регулярно (раз в несколько минут) меняются местами. Когда один пишет код, второй его анализирует.

Здесь возникает вопрос, как соотносятся Agile и Scrum. Мне очень понравился ответ, который я увидел где-то на просторах Facebook: примерно так же, как газировка и кока-кола.

Важно понимать, что далеко не во всех компаниях внедрен чистый Scrum или Kanban. Зачастую компания пишет, что работает по скраму, когда у них тупо итерационная разработка, а все прочие условия скрама не соблюдены. Кроме того, на рынке появляются всякие гибридные варианты, которые создают компании. Тот же Сберджайл, например (думаю, не стоит объяснять, в какой компании он применяется, да?).

Развитие гибких систем разработки привело к появлению таких специалистов, как, например, Agile Coach (аджайл-коуч) и Scrum Master (скрам-мастер). Они знают, как создавать, запускать и выстраивать процесс гибкой разработки. Причем их функционал в основном не технический: их сильная сторона – soft skills, за счет чего они становятся одновременно и преподавателями (обучают технологии гибкой разработки), и фасилитаторами (облегчают общение внутри команды), и специалистами по устранению системных препятствий на пути к реализации и продвижению продукта, и выполняют много других функций, благодаря чему проект «едет» в соответствии с принципами Scrum или Agile.

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

Глава 9
Управление в IT

Итак, мы разобрали методологии, по которым разрабатывается продукт. Есть те, кто будет следить за соблюдением канонического скрама, но есть ведь и те, кто будет непосредственно управлять процессами, да? Давайте рассмотрим тему, которая вызывает много сложностей у рекрутеров: Product– и Project-менеджеры. Чтобы понять суть этих специальностей, давайте определимся с разницей между проектом и продуктом.

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

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

Например, продукт – это новое мобильное приложение для инвестиций. Его разработка будет предполагать множество проектов. Один из них, например, – запуск сайта. У этого проекта есть свои начальные и конечные точки исполнения.

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

Product manager, или менеджер продукта, отвечает за успех продукта в целом. Определяет стратегию и тактику его создания и доработки. Его основная задача – делать все возможное для постоянного совершенствования продукта на каждой стадии его жизненного цикла.

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

Именно Product-менеджер собирает требования к продукту (или работает в этом вопросе в паре с аналитиком), распределяет задачи в бэклоге и принимает стратегические решения по продукту (какую фичу мы будем делать, а какую нет).

Для работодателя, который ищет кандидата на эту позицию, может быть важно, чтобы у того был аналогичный опыт работы, например, в b2b– или b2c-сфере. Также Product-менеджер может иметь в «анамнезе» позицию UI/UX-дизайнера или, возможно, даже разработчика (это реже).

Ну и конечно, Product-менеджер часто отвечает за финансовые показатели продукта, за различные финансовые цели: как количество пользователей продукта вырастет на такой-то процент, как увеличить прибыль по тому или иному каналу.

На job-бордах также можно встретить Product marketing manager. Это как раз те, кто занимался маркетинговым позиционированием продукта. Частично функционал с обычными продакт-менеджерами у них может быть схожим, но это все-таки люди, которые заточены на продвижение продуктов.

Project manager, или менеджер проекта (PM – читать «ПиЭм»), – это специалист, который фокусируется на процессе реализации проекта. Он координирует команды и отвечает за сроки. Его задача – разбить проект на задачи, оценить существующие ресурсы и ограничения и, исходя из этих знаний, спланировать все активности по проекту. То есть определить, кто что делает, выставить адекватные сроки и скоординировать команду так, чтобы она работала максимально эффективно.

Его главная цель – воплотить идею заказчика в установленный срок, используя существующие ресурсы.

Как видите, Product-менеджер должен обладать бо́льшим набором навыков, чем Project-менеджер. Первый из них более глубоко погружен в разработку самого продукта, он имеет влияние на его развитие, принимает бизнес-решения и вовлекает маркетинг. А второй отвечает за то, чтобы проект достиг своей цели, и выполняет административные функции.

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

Кроме того, в гибких подходах к разработке (Agile) чаще всего нет места Project-менеджеру: эта специальность в большей степени относится к каскадной разработке. А как раз роль Product-менеджера характерна для гибких подходов. Хотя, опять-таки, все зависит от каждого конкретного случая. Наш рынок, к сожалению, сложно грести под одну гребенку и жестко структурировать, поэтому на нем порой появляются очень странные детеныши разных подходов.

Product owner, или владелец продукта, – еще одна руководящая должность, пришедшая из скрама. Этот специалист отвечает за продукт на уровне команды. Его цель – донести до нее видение продукта целиком, ответить на все «почему?», «зачем?» и «как?», прописать пользовательские истории, приоритезировать и почистить бэклог.

Это очень важная роль, которая будет исполняться в тесном тандеме с Product-менеджерами с одной стороны и командой разработки – с другой. Владельцу продукта может быть делегировано «представительство продукта» перед разработчиками, в то время как Product-менеджер и его команда сосредоточатся на стратегии и проработке видения продукта.

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

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