Данная статья не должна служить каким-то руководством к определенным действиям. Я старался расписать все со стороны разработчика и на собственном опыте, с учетом своих ошибок в том числе.
Я думаю, что правильней будет расписать все тезисно с учетом примеров из реальной жизни.
1. Документация – это основной документ разработки.
Любая задача будь она сложная или нет должна начинаться с формализации. В ходе описания функционала решается достаточно много вопросов, которые могут встать в том числе и после релиза определенных фич. Кроме того, это позволяет трезво осмыслить весь спектр задач и расставить им приоритет. Также документацию можно показать реальным будущим пользователям и снять с функционала еще больше вопросов.
В моей практике почему-то все пошло изначально не по вышеописанному плану. Задачами загрузили на столько, что мало того, что документацию описать, времени отчасти на проектирование не хватало. Это все привело к увеличению времени разработки. Так как двух рук разработчика рано или поздно стает мало, то нанимается персонал, на который распределяется нагрузка. Но в отсутствии документации это приводит к очень серьезным последствиям:
- Персонал начинает дергать других людей, чтобы уточнить тот или иной вопрос. Но у тех, к кому они обращаются тоже есть своя зона ответственности. При увеличенных темпах работы это приводит к не очень дружелюбной атмосфере в команде.
- Так как персоналу не откуда брать информацию по проекту, кроме как спросить или проаудировать код, то КПД этого ресурса сводится на первых парах к 0.
- Не зная о всех взаимосвязях новый разработчик, реализовывая новый функционал может просто поломать всю систему. А в не очень организованной команде – это сначала узнают пользователи, которые и выливают весь негатив.
Сложно недооценить этот пункт. Это база, вокруг которой все должно строиться. И пренебрежение этим на первых этапах приведет к увеличению производительности команды, но в конце концов сведет эту самую производительность на нет.
Я на своем опыте могу сказать, что, написав какой-либо код вчера, сегодня ты можешь и не вспомнить что к чему относится и какие взаимосвязи у блоков (приходится аудировать код и заново рисовать картину в голове). А документация очень в этом помогает.
2. Контроль выполнения задач и отчеты
Никто не спорит, что выполнение задач необходимо контролировать. Для того, чтобы это осуществлять не обязательно производить ежедневные дейли (что на самом деле, с другой стороны, позволяет держать себя в тонусе, но занимать они должны не более 5 минут времени), тем более требовать еженедельные/ежедневные отчеты. Все должно быть видно по закрытым задачам (про задачи поговорим немного позже).
Когда мы только начинали реализовывать проект, то наши дейли бывало доходили до 2 часов. А от постоянных созвонов ты не только сильно устаешь, они не дают тебе сконцентрироваться на своих задачах. Я считаю, что структура созвонов должна учитывать и вовлеченность участников проекта, но не должна быть избыточной. Меня, допустим, как основного разработчика ни разу не брали на совещание по планированию развития проекта – такого быть не должно. Но, к примеру, часто дергают на совещания по вопросам, которые отчасти меня не совсем касаются. Все основные участники проекта должны быть вовлечены в том числе в планирование. В нашем случае, что-то было спланировано без участия отдела разработки – что конкретно тоже по итогу не известно (см п. 1). Ну, и как следствие, отсутствия в организации работы над проектом документации – ежедневный контроль и отчеты, чтобы руководству самому понять в правильном ли направлении они двигаются.
3. Четкость постановки задач – это путь к успеху
Всегда вспоминаю популярную поговорку: “Без четкого ТЗ и результат ХЗ”. Никогда не нужно пренебрегать подробным расписыванием задачи, даже если кажется, что какие-то вещи очевидны. Очевидны они в первую очередь только вам и всегда лишний раз лучше пояснить ту или иную вещь.
В моей практике некоторые задачи сводились примерно к таким фразам:
- Необходимо реализовать авторизацию пользователей! – какую авторизацию? С подтверждением или нет? OAUTH? JWT? А может сначала регистрацию пользователей?
- Необходимо реализовать отчет по продажам! – за какие периоды? По каким товарам? Какие столбцы таблицы? Табличный?
Я думаю, понятно, что чем ты подробнее раскроешь задачу, тем более приближенной к эталонной будет ее реализация.
Кроме того, крупные задачи необходимо декомпозировать. В том числе и для того, чтобы был прозрачен процесс разработки и задача не перемещалась из спринта в спринт из-за того, что ее просто не успевают закрыть. А для руководства – это отсутствие деятельности участника команды, так как не выполняется критерии эффективности, а именно – закрытие задач.
4. Фокус на быстром запуске, а не на качестве
Этот тезис изначально ошибочный. Всегда нужно ставить на качество продукта. Необходимо производить тщательное тестирование функционала перед тем, как показать его конечному пользователю
В моей практике было даже еще хуже: конечному пользователю изначально обещался еще не разработанный функционал. Мало того, что руководство тем самым ставило себе неосуществимые и тем более не зависимые от них дедлайны, так потом от этого страдала вся команда: все старались успеть в этот искусственно загнанный дедлайн. Что страдает первое от данного подхода? Конечно, качество реализации! Потом сам пользователь начинает всех участников команды тыкать в недоработки как маленьких котят, к самим пользователям так же подключается руководство… Тогда иногда встает вопрос: так на чьей руководство стороне?
Также, если идет текущий спринт не нужно пытаться реализовать задачи, которых изначально при планировании не было. Да, никто не спорит о том, что в ходе использования функционала бывают найдены критичные баги и недоработки – но это должно быть исключением нежели правилом. В своей практике я несколько раз просыпался и видел посреди спринта добавленные 50-60 задач.
5. Тестирование функционала
В предыдущем пункте я частично коснулся этого момента. Пренебрежение тестированием, я считаю, второй по негативному влиянию на судьбу проекта грех. Всегда нужно производить несколько циклов тестирования, даже если в каком-то цикле ничего не нашлось. Кроме того, необходимо давать разработчикам время на покрытие своего кода юнит-тестами, что кратно бы увеличило качество разработки. Да, скорость упадет, но результат будет такой, какой планировали. Еще грамотнее взять в штат отдельного специалиста по тестированию, с определенным уровнем подготовки.
В наших же реалиях продукт мало того, что тестировался конечными пользователями и собирался негатив. Так еще и теории руководства проверялись непосредственно разработкой. Представьте какого специалисту реализовать тот или иной функционал, а потом узнать, что это действие было избыточным и оно вообще никому не нужно…
6. Не нужно пренебрегать универсальностью команды.
Все понимают, что у стартапов, как правило, ограниченные ресурсы. Но и на энтузиазме команды долго никуда не уедешь. Да, первичная мотивация может какое-то время спасать. Но чем больше проект разрастается, тем больше ресурсов он требует. И их необходимо восполнять. Речь сейчас не только о разработке, а о команде в целом. Один человек недолго может совмещать в себе несколько должностей. Я, к примеру, и backend, и frontend разработчик, и devops, и тимлид и HR еще иногда, когда требуется расширение команды или восполнение ресурсов. Но помимо дополнительных обязанностей у тебя еще есть и свои, которые также требуют выполнения.
7. Рабочее время – это работа, не рабочее – личная жизнь
Изначально нужно договориться с командой кто в какое время доступен и беспокоить только в это время. Как говорится: работа работой — но у каждого есть личная жизнь и между ними должна быть четкая граница. Также я категорично против сверхурочной работы. В большинстве случаев, сверхурочная работа имеет только едино моментный эффект и не всегда продуктивный. Кроме того, я считаю, что при грамотно выстроенном процессе разработки сверхурочки и переработок быть не должно. В целом, для сохранения продуктивности и баланса человеку нужен отдых и переключение.
Также очень важно прислушиваться к участникам команды. В моей практике был случай, когда я прямо говорил руководству, что я выгорел, у меня апатия и мотивация ниже плинтуса – а мне говорят: Слушай, давай поработаешь в выходные и можешь в будни работать побольше? Для меня это было просто красным флагом.
8. Не стоит менять вектор развития, если план утвержден
Не нужно думать, что процесс разработки является очень гибким. Очень важно, если ранее было спланировано, что в определенный момент должен быть реализован тот или иной функционал, не менять резко планы.
Для каждого участника команды важен конечный результат, а когда его не видишь, из-за того, что резко меняются приоритеты, то от этого ты начинаешь понимать, что твои усилия нисколько не стоят. Более того, ты начинаешь понимать, что фактически никто не знает к какой цели движется. Это очень демотивирует.
В моей практике изначальная идея разделилась на три проекта. В течение некоторых промежутков времени руководство резко меняло приоритеты разработки: сначала пилим первый, резко переключаемся на второй и тд. Самое смешное, что по итогу все равно вернулись к первому. Но в ходе скаканий по проектам по итогу ни один из них так и не был до конца закончен. Чем сейчас по итогу руководство и начинает попрекать команду. А она фактически в этом не виновата.
9. Мотивация команды – это не пустой звук
Про ограниченные ресурсы стартапов я уже писал. Но мотивация команды должна быть соответствующая уровню решаемых вопросов. В моем же случае, помимо оклада и премии были еще договоренности. Но в силу жуткой усталости от проекта это нисколько не мотивировало, а наоборот с каждым днем я понимал, что изначальные договоренности теряют свою актуальность. Поэтому, если все же проекту быть, то никогда не нужно забывать про команду и своевременную индексацию оплаты труда участникам проекта.
Так же мотивация не должна превращаться в демотивацию. В моей практике было несколько случаев, когда просили поработать сверхурочно, якобы потом компенсируется либо выходными, либо премией. Но по итогу, после едино моментного ускорения и закрытия задач про это благополучно забывалось. Никогда не стоит забывать про изначальные договоренности.
10. Не нужно злоупотреблять кризисным менеджментом.
Если в ходе разработки проекта случается кризис, то это, как правило, следствие действия или наоборот бездействия. Многие считают, что это должно держать команду в тонусе, но имеет все же обратный демотивирующий и разрушающий эффект. Стресс в рабочей экосистеме одного из участников команды очень заражает других, убивая их продуктивность и мотивацию.
В нашем же проекте кризис возникал по причине кучи багов из-за высокой скорости разработки и упущения многих процессов, про которые я ранее писал, и отсутствия действий, которые необходимо было реализовывать. Ярким примером может быть выставка, к которой нужно было готовиться с начала года, но мы почему-то сфокусировались на другом проекте, который по итогу снова забросили…
11. Критерии оценки эффективности участников команды.
Очень многие грешат тем, что оценивают эффективность участника команды по количеству закрытых задач или количеству строк внесенного кода. Но это очень глубокое заблуждение, так как объем работы по конкретной задаче может быть очень разный, а где-то нужно протестировать не слетели ли другие части системы из-за внесенного изменения. Не зря я ранее писал про декомпозицию. В моем случае, одна даже не сильно сложная задача бывает выливается в 10-20 подзадач, так как необходимо учесть много зависимостей, а в отсутствие покрытия хотя бы юнит-тестами еще и протестировать функционал.
Кроме того, не нужно забывать, что, участвуя в созвонах и обсуждениях, человек тоже тратит свои ресурсы и свое рабочее время. Помните, я писал про дейли по 2 часа в день? После такого, если честно и работать не очень хочется в силу того, что созвоны очень сильно выматывают. Также давая какую-то дополнительную срочную задачу, нужно понимать, что прогресс по другим будет смещен вправо. И это не будет зависеть от того, что сотрудник не эффективен, просто его время было занято другими вещами.
12. Пообещал – выполняй
Этот тезис я уже поднимал выше не один раз. Это на самом деле относится ко всем участникам команды. Со времен фриланса я еще понял, что когда тебе что-то обещают и не выполняют, то это классический кидок: на деньги, время, интерес и тд.
В нашем же случае, если есть какие-то договоренности между участниками команды, то их нужно выполнять. Понятно, что бывают форс-мажоры, сейчас речь не про них. К примеру, возьмем наш проект: перед каждой крупной итерацией работы над проектом нам руководство говорило: вот доделаем этот блок и скорость разработки снизится, будем писать документацию и тд. По итогу же ни о каком снижении скорости речи не идет. Наоборот, с разрастанием проекта она только увеличивается.
13. Проблема оценки сроков
Достаточно часто в командах ставится вопрос о некорректной оценке сроков. Почему? Потому что не учитываются многие вещи (в данном случае, я опишу на нашем примере):
- Нет понимания объема задачи из-за некорректного ТЗ
- Нет понимания тех блоков, которые также будут затронуты при разработке и где-то нужно будет настраивать обратную совместимость. Тут, возможно, встанет вопрос: “Как нет понимания, если большую часть кода ты написал?”. Очень просто – я вас отошлю к п. 1 данного списка. Там я писал, что подробностей того, что ты сделал сегодня, завтра можешь и не вспомнить.
- Нет понимания четкой загрузки в данный период. Тем более, если есть злоупотребление кризисным менеджментом. Так как функционал может быть тщательно не оттестирован, критичных вещей на правки может прийти достаточно много.
- Отвлекающие факторы: опять же нет понимания на скольких совещаниях ты будешь, нет понимания по скольким вопросам тебя дернут для разъяснения того или иного функционала, так как документация отсутствует.
- Форс-мажоры. Та же болезнь или семейные обстоятельства могут сдвинуть сроки вправо.
Кроме того, если стараешься называть плюс/минус адекватный срок, то в эту же минуту ты можешь попасть в процесс торгов: по срокам, сверхурочке и подобным вещам – что также негативно сказывается на мотивации. Тут ты понимаешь, будет быстро и плохо, так как времени на более тщательное тестирование и проектирование у тебя нет.
Надеюсь, что описанные выше тезисы кому-то помогут избежать тех ошибок, что совершили мы. Также, я думаю, статья еще будет корректироваться и дополняться.
