Привет! Хочу поделиться наработками по налаживанию процесса разработки. Вместе пройти путь от найма сотрудников до тестирования ПО.
Краткое содержание
Допустим вы проснулись утром лидером стартапа после первого раунда инвестиций, выпили кофе и неотлагательно приступили к работе. В чек листе значатся:
Поиск сотрудников.
Собеседование.
Выбор технологий для проекта.
Организация команд.
Планирование. Документирование. Архитектура.
Постановка задачи. Разработка. Тестирование. Контроль.
Административные дела.
Инструменты.
Литература.
Поиск сотрудников
Поиск сотрудников в IT - это боль. Рынок кандидатов и так мал, а тут еще крупный банк открыл офис разработки в нашем городе и пылесосит кадры.
Из очевидного
(глагол?) Услуги специализированных площадок: hh, linked. Если позволяет бюджет - расширить географию и упомянуть помощь в переезде для кандидатов из другого города.
Из нестандартного
Искать среди докладчиков и зрителей на конференциях.
Просматривать вклады в опенсорс проекты по схожим или смежным проектам на GitHub, BitBucket, GitLab.
Не забыть про активных пользователей ресурсов аля stackoverflow в разделах релевантных технологий.
Использовать сарафанное радио (коллеги уже нанятых сотрудников).
Устраивать конкурсы с призовыми фондами и предложением дальнейшего трудоустройства.
Искать на фриланс биржах.
Устраивать открытые конференции в офисе компании.
Организовывать дни открытых дверей на интересную тему, даже если “интересное” - это только добротный офис с бесплатными печеньками.
Собеседование
На собеседованиях важно грозно смотреть на кандидата и усердно надувать щёки. А еще заваливать самыми сложными задачами на знание алгоритмов. Ведь так же делают крупнейшие IT компании!
Если кроме шуток, то кандидаты должны уходить довольными, даже в случае отказа. Ну, по крайней мере, будем стремиться к подобному.
Помогает короткая отвлеченная беседа перед технической частью. Улыбка и волшебная фраза “сам не люблю ходить на собеседования, сам не так давно был(а) на вашем месте“ расслабит кандидата и даст больше шансов раскрыться. Технические вопросы лучше задавать по нарастающей сложности, фиксируя условную оценку по каждой секции. Это сильно помогает, когда кандидатов много.
Состав технических вопросов напрямую зависит от того, кого ищем - перспективного специалиста с хорошей базой, на которого можно потратить условные полгода на обучение или узкого специалиста с опытом в вооооот этой технологии.
Помимо технических навыков, важен навык работы в команде. Пару вопросов о бывших коллегах, начинающихся с “как” или “что”, прольют свет на конфликтность кандидата. Не ленитесь посмотреть профиль будущего сотрудника в социальных сетях. И не стесняйтесь узнать мнение бывших коллег и руководства кандидата прямым звонком или письмом. Но важно помнить, что на той стороне тоже бывают недобросовестные люди.
Хорошая практика - познакомить кандидата с командой и их работой до подписания трудового договора.
Если работа удаленная - уточнить о наличии: тихого места, стабильного интернета и навыков самоорганизации.
Выбор технологий для проекта
По моим наблюдениям IT сообщество падко на хайповые технологии, но мы так поступать не будем, потому в первую очередь смотрим на:
Специфику проекта.
Знания и опыт текущих сотрудников.
Возможность развивать инструмент или технологию.
Пример к последнему пункту.
Взять сырую, но перспективную технологию для стартапа, довести до ума и получить профит в долгосрочной перспективе. И напротив - взять махровую библиотеку для банковского проекта, которая ну очень стабильна.
Организация команд
С технологиями определились, людей наняли. Формируем организационную структуру.
Мой любимый вариант - атомарные команды по 6-12 человек. Чтобы в команде присутствовали необходимые роли: менеджеры, тестировщики, разработчики и др. При этом некоторые роли могут одновременно работать в нескольких проектах. Например дизайнеры и тестировщики.
У руководителя в прямом подчинении не более 7 сотрудников.
Важно вести и корректировать документ с плюсами и минусами сотрудников.
Иван Иванов | C#, Mongo, TypeScript | Добротная экспертиза в БД. Неконфликтный, хороший ментор | Не любит алгоритмы. Нуждается в мотивации.
Хорошо, когда команды комплектуются не только по техническим навыкам, но и с учётом двух последних колонок. Например разбавить команду ментором, чтобы подтягивать новичков. Или новатором, чтобы привносить новые технологии и инструменты.
Руководителям команд важнее уметь разбираться в тонкостях человеческих взаимоотношений, чем в тонкостях кода. По заветам системной инженерии в идеале нужны 2 руководящие должности - технический лидер и администратор.
Планирование. Документирование. Архитектура
Бюрократия - зло, но без неё - никак.
Планирование
У проекта ведется план, который нужно регулярно пересматривать и корректировать. Пусть в виде записей огрызком карандаша в блокноте.
первая версия ядра - 12.04
отчёты - 02.06
интеграции - 25.07
бета-версия - 14.09
сдача проекта - 01.11
Документирование
Думаем о документировании, как о вкладе в будущее. Документируем: план проекта, конвенцию по стилистике кода, требования заказчика, изменение требований, программную и аппаратную архитектуры. Документация должна быть краткой и максимально понятной. Если документ не понятен - он не будет использоваться, а будет только мешать. Важные договоренности фиксируем в письменном виде. Описание инсталляции и компиляции включаем в Readme репозитория.
Архитектура
Архитектура формируется до написания кода. Желательно в текстовом и графическом виде. При проектировании будем использовать паттерны проектирования, учитывать предполагаемое количество пользователей и искать готовые решения. Например - архитектурные шаблоны.
Заведём глоссарий. Это облегчит общение как внутри команды, так и при переговорах с заказчиком. Как минимум не будет путаницы в названиях переменных.
Постановка задачи. Разработка. Тестирование. Контроль
Задачи - есть. Люди - есть. Пора налаживать рабочий процесс.
Разбёрем каждый из этапов рабочего процесса и подберём методологию разработки.
Первое - выбор методологии разработки ПО. Не стесняемся адаптировать её под проект. Ведь не существует проектов, которым идеально подходит та или иная методология.
Второе - выбор варианта ветвления в Git. Тут перечислены самые популярные. Для себя выберем Github Flow.
Постановка задач
Для постановки задач используем менеджеры задач. Они дают прозрачность разработки, повышают качество и сводят к минимуму избыточное общение между участниками.
Минимальный набор полей у каждой задачи:
Проект.
Срок.
Ответственный.
Приоритет задачи.
Описание.
Для баланса нагрузки по исполнителям и контроля сроков, важно держать сроки и приоритетность задач в актуальном состоянии.
Распределим задачи с учётом сильных и слабых сторон сотрудников. Будем стараться как можно реже перебрасывать людей с проекта на проект и с задачи на задачу. С другой стороны не будем давать людям застаиваться и скучать на однообразных задачах.
Моя любимая старая-добрая памятка по этому разделу:
Полученное задание анализируется перед началом работы. Само-собой это накладывает обязательное наличие требуемой компетенции у сотрудника.
Полученное задание выполняется на 100%. Т.е. любое задание должно иметь чёткий критерий завершённости. Соответственно, пока он не выполняется — задание считается незавершённым.
О препятствиях для полного выполнения задачи необходимо незамедлительно сообщить руководителю и всем заинтересованным лицам. То есть не скролить котиков, ожидая, что руководитель сам догадается, что у тебя с выполнением проблема и волшебным образом её решит.
Предложение по решению проблемы предпочтительней информации о её появлении. Подразумевается (зачастую), что исполнитель — эксперт, понимает что пошло не так и как эту беду можно быстро разрулить.
Расширенное толкование полученного задания не допускается. Не надо, мол, додумывать за руководителя что он имел в виду. Лучше уточнить.
Несогласие с параметрами задания или регламентами исполнения не может служить поводом для их игнорирования.
Факты и аргументация предпочтительней мнения. Фразы типа «Мне кажется — не взлетит. Поэтому делать не надо» — не то, что хочется слышать в ответ на постановку задачи. Считаешь, что не взлетит — обоснуй, подтверждая фактами.
Разработка
Возьмём для примера условную задачу из воображаемого проекта “№545 Add hotkeys support for a search”.
Имя git-ветки будет соответствовать смыслу задачи, например: “LCC-545-search-hotkeys”.
Перед каждым коммитом проверяем изменения в отредактированных файлах, для минимизации ошибок.
В сообщение коммита добавим номер и заголовок задачи, для навигации по истории изменений. Пример: “LCC-545 Add hotkeys support for search”.
Перед отправкой задачи на тестирование сверим описание задачи с результатом.
Создадим пул-реквест для повышения качества кода и обмена опытом.
Направим задачу на этап тестирования, после одобрения пул-реквеста.
Тестирование
Тестирование - как профилактический поход к стоматологу раз в полгода - все понимают важность, но мало кто делает.
Не стоит сразу стремиться к 100% покрытия кода тестами, лучше выделить и написать тесты для ключевых и “узких” мест в приложении. Таким образом получаем защиту от регрессий при небольшом количестве дополнительного кода.
Разделим тестирование на ручное и автотесты: unit тесты, интеграционные тесты, E2E тесты, нагрузочное тестирование.
Unit тесты
Подходят для изолированных частей кода, в особенности чистых функций, результат которых зависит только от входных данных. Возьмем за правило использовать не только корректные выходные данные, но и заведомо ложные. Для громоздких результатов функций будем использовать “snapshots”.
Интеграционные тесты
Тестируем взаимодействие модулей. Это быстрый способ проверки регрессий в большом объеме кода. Из минусов - не видно, где конкретно возникла проблема и повышенные требования ко входным и выходным данным.
E2E тесты
End-to-end тесты - отличный способ поверить сквозную функциональность в веб разработке. Например: функционал авторизации, заказ товара, построение отчёта. E2E не требует знаний технологий проекта, достаточно владеть фреймворком для тестирования.
Нагрузочные тесты
Хороший способ отловить сильно “потяжелевшую” функциональность в релизе. Обязательно к применению, если у вашего проекта уже есть: сколь значимый трафик или тяжелые вычисления.
Ручное тестирование
Ручная проверка результата выполненной задачи и общей функциональности проекта, помогает там, где нет автоматизированных тестов или где они не работают: поехала верстка, проблемы с доступностью (accessibility), функционал неудобен и прочее.
Подход не требует навыков в разработке, тем самым экономит ресурсы дорогостоящих разработчиков.
Контроль
Начинаем с логики задачи.
Постановщик проверяет, что результат соответствует описанию задачи и не нуждается в доработке. Если задача поставлена некорректно, либо выполнена не в полной мере, она возвращается на этап разработки, с соответствующими комментариями.
Ревью кода (PR).
Тут повышается качества кода и разработчики обмениваются опытом.
Набросаем примерный чек-лист:
Можно ли упростить?
Код на верном уровне абстракции?
Код разбит на модули?
Приходит ли на ум решение, которое лучше по: поддерживаемости, читабельности, производительности и безопасности?
Существует ли похожая функциональность в кодовой базе?
Есть ли “лучшие практики”, шаблоны проектирования или специфические для языка шаблоны, которые могли бы существенно улучшить этот код?
И кстати, для проверки стиля, отступов и прочего используйте линтеры.
На этом же этапе тезисно записываем результаты работы по каждому сотруднику в таблицу. И далее подбиваем результат в конце: недели, месяца, квартала, года, чтобы объективно оценить работу человека за выбранный период.
CI/CD
Крутая штука. Сокращает время выпуска релизов. Улучшает: масштабируемость, отказоустойчивость, документацию.
Выбираем и настраиваем одну из платформ автоматической сборки, тестирования и загрузки кода.
Одну среду сделаем для разработки, где автоматически будут разворачиваться ветки из пулл реквестов. Пример адреса - “lcc-821 -add-another-pyment-system.pr.lcc-project.com“.
Другая среда будет схожа с production версией, для финального тестирования релизов.
Третья среда - production версия.
Административные дела
Кроме процесса разработки, нужно помнить о:
Других важных ролях в компании
Обучении и обмене опытом среди разработчиков
Атмосфере в компании
Мотивации
Другие важные роли
Наш проект предусматривает сбор и анализ большого объема требований с последующим анализом и документированием.
Потому нам жизненно необходимы технические писатели и аналитики.
С первыми все просто - они здорово облегчают ведение внутренней и внешней документации.
С аналитиками немного сложнее. Они знают и предметную область и продукт. Собирают требования или анализируют проблемы, превращая их в словесное описание того, что нужно сделать в продукте.
А ещё всё, что насочиняли аналитики и написали разработчики нужно хорошенько протестировать. Потому тестировщики просто незаменимы. Они лучше всех знают продукт со стороны пользователя и здорово экономят время других ролей.
Обучение и обмен опытом
С профессиональным ростом сотрудников растёт и качество проекта.
Поэтому будем выделять время для:
Перекрестного ревью кода.
Парного программирования.
Внутренних митапов. Имеют смысл, когда команды работают изолированно.
Организации пространств для взаимодействие команд. Например канал в корпоративном мессенджере по техническим вопросам.
Атмосфера в компании
Возьмём на заметку: контроль конфликтов, выгорание, обратную связь.
Токсичные сотрудники - те, кто препятствует нормальной работе коллег. Таких просим на выход, если не получается оградить коллектив от их влияния.
Выгорание - продолжительное ощущение измученности, снижение продуктивности. Решения: длительный отпуск, смена деятельности или проекта. В противном случае компания рискует лишиться сотрудника.
Обратная связь от руководителя - мощный стимул для развития сотрудника. Придерживаемся простого правила: награждаем публично, а ругаем - лично. Информацию подкрепляем фактами и стараемся быть максимально непредвзятыми.
Мотивация
Команда должна любить то, что делает, а каждый чувствовать себя её частью.
Для этого будем доносить до сотрудников обратную связь пользователей. Подключать команду к решению общих вопросов.
Сотрудник должен быть уверен, что его поощрят за успехи и будут порицать за промахи.
Поощрения могут быть как материальные: премия, оплата курсов, конференции.
Так и не материальные: повышение, возможность внедрить новую технологию, публичная похвала.
Примеры порицания: отсутствие премии, переключение на скучные задачи, давление команды (осознание, что ты подвел команду).
Инструменты
Выбор инструментов напрямую влияет на успех и эффективность проекта.
Общее
Используйте инструменты для внедрения статической типизации, если у используемого языка динамическая типизация.
Не экономьте на железе и софте.
Подключайте линтеры для автоматического контроля качества кода.
IDE
Продукты компании JetBrains, VS Code.
Таск-менеджеры
Asana, Trello, Click-up, Jira.
CI/CD
TeamCity, CircleCI, Travis CI, GitLab.
Тестирование
Cypress для E2E. Jmeter для нагрузочного тестирования.
Документирование
Confluence, Google Doc, Wiki.
Литература
Рекомендую:
“Мифический человеко-месяц” - Фредерик Брукс.
“Rapid Development” - Steve McConnell.
“Deadline” - Том ДеМарко.
“Сделано. Проектный менеджмент на практике.“ - Скотт Беркун.
Выводы
Сотрудники наше все. Используйте нестандартные источники для поиска кандидатов. Вопросы для собеседования подбирайте в соответствии с будущими задачами. После собеседования у кандидатов должно сформироваться положительное впечатление о компании.
При выборе технологий учитывайте: специфику проекта, знания и опыт текущих сотрудников, возможность развивать инструмент или технологию.
Разделяйте сотрудников на атомарные ячейки. Ведите учёт навыков у членов команды. Уделяйте пристальное внимание социальным навыкам при выборе лидеров команд.
Пишите документацию. Как минимум общую архитектуру и бизнес-логику. Ведите план проекта. Фиксируйте договоренности в письменном виде. При проектировании используйте архитектурные шаблоны. Пишите коротко и понятно.
Подберите методологию разработки ПО и определите этапы разработки. Используйте менеджеры задач. Пишите тесты для поиска регрессий и контроля масштабируемости.
Организуйте ревью кода. Автоматизируйте CI/CD.
Включайте в команду тестировщиков и аналитиков. Вкладывайтесь в профессиональное развитие сотрудников. Команда должна видеть обратную связь и за успехи и за промахи.
Ищите способы автоматизировать рутину, будьте в курсе популярных сервисов и инструментов.
Выделяйте 20 минут в день для прочтения статей и время, на прочтение книг.
NiPh
В разделе найма ни слова про удаленную работу?
Argon Автор
Большая часть раздела касается и офиса и удалёнки.
В разделе "Собеседование" упоминается