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

Когда достигается момент, когда продукт вроде бы уже готов, и теперь-то хлынут финансовые потоки на счета компании — не тут-то было. Рынок так просто не принимает новичков. Даже с продуктом. Руководство становится нервным, начинает активно взбивать лапками масло, чтобы сохранить темпы развития и таки выйти на рынок в полный рост.

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

Думаю, не стоит рассказывать, к чему такое может привести.

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

Как говорится, за двумя зайцами погонишься — ни одного не поймаешь.

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

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

Анализ крупной задачи

Даём в качестве примера одно из крупных приложений (для JS-разработчиков я брал календарь от Google) и просим кандидата проанализировать, сколько бы у него заняла разработка такого приложения: 1) общий срок; 2) самые сложные компоненты; 3) какие он видит тонкие нюансы. В ходе анализа задаём вопросы, какими бы средствами (библиотеками, компонентами) можно было реализовать тот или иной функционал.

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

Проверка аргументации

Даём нехитрый вопрос, который решается шаблонно каждый день. Например, как организовать хранение конфигурационных файлов для приложения. Любой программист легко отвечает. А дальше спрашиваем: «а почему именно так?» Терпим изумлённую паузу и слушаем варианты аргументов. Затем усложняем задачу: «а как дифференцировать конфиги для локальной, тестовой, препродакш и продакшн сред?» Потом бомбим вопросами «а как ещё можно», «а почему именно так», «а какие преимущества и недостатки»… Задача программиста сводится к поиску альтернатив и аргументированному выработке единственного правильного решения. Если разработчик не может этого сделать, то он нам мало интересен.

Цель: фильтруем людей, которые делают бездумные вещи просто потому что «всегда так делают»

Стресс-тест

Даём небольшой кусок кода, который бы компилировался, но со стороны выглядел необычно и нелогично. Просим указать в нём на ошибку. Кандидат как правило долго его разглядывает, рассуждает, где бы она могла быть, мнётся и смущается. Дальше идёт примерно такой давящий диалог:

- Ну и где там ошибка?
- Да как-то непонятно…
- Так всё же?
- Ну вот тут вот так никто не делает…
- И что? Какая ошибка будет?
- Да вроде не должно быть…
- А где тогда?
- Да так сходу непонятно. Вроде бы всё нормально…
- Так что же, ошибки нет?
- Ну в задаче же сказано, что её надо найти, значит, наверное, есть?
- Ну и где она?
- Сейчас…. (минуту ещё внимательно перечитывает, скрипит мозгом) …ну вроде бы нету…
- Точно?
- Ну вроде да…. не должно быть…
- Вы уверены???
- Нет, но я её не вижу.
- НЕТ ОШИБКИ???
- Ну…. нет.
- ТОЧНО???!
- Нету.
- (спокойным тоном) Ну да, действительно, здесь нет ошибки. Перейдём к следующему вопросу.
- (шумный вздох облегчения)

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

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

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

В моей команде, в принципе, свободный график (работай когда удобно, лишь бы работа выполнялась), и народ подтягивается на работу начиная с 9 утра и заканчивая часом дня. Уходят, соответственно, в 7-10 вечера. Однако чтобы блюсти дисциплину и не распускать это ещё дальше, ввели правило: каждый, кто приходит после 11:30, приносит килограмм мандаринов/бананов/яблок. Да, опаздывать меньше никто не будет, но зато убили кучу зайцев:

• обозначили максимально-приемлемое время прихода (критерий оценки дисциплины) или, другими словами, договорились, «что такое хорошо и что такое плохо»;
• польза для всей команды от опоздавших — все едят витамины
• снят стресс с опоздавших. Они будут меньше переживать на счёт своей задержки, поскольку точно знают, что на начальник не будет срываться на них и устраивать истерики. Всё ограничится фруктами.

Исходные данные

Имеем сработавшуюся команду из 5 разработчиков.

Моделируем два кейса:

1. набираем 3 новых разработчиков к себе в штат;
2. связываемся с внештатной командой из 3 человек.

В обоих случаях оцениваем прирост в стоимости и производительности через полгода и год.

Учитываем, что ввод новых людей в курс дела займёт 6 недель, и при этом их производительность  будет расти от 50% до 100% и плюс к этому они отвлекают старых членов команды. То есть получаем яму в производительности. После того как они сработаются, берём накапливающийся коэффициент производительности 1.01. То есть командный эффект будет влиять от недели к неделе на 1%. Также учитываем трату времени на коммуникации в командах: чем больше в них людей, тем больше тратится времени.

В случае привлечения удалённых разработчиков учитываем, что с нашей стороны потребуется тратить дополнительно 35 часов в неделю на консультации, SCRUM-митинги, демонстрации, code-review. А также учтена отсрочка начала работ на 4 недели для подготовки ТЗ и прочей документации, понятной чужим людям.

Стоимость штатных программистов возьмём из расчёта $15/час, а удалённых — $25/час

Результат

Вывод из этого всего мы сделали такой: внештатники в краткосрочной перспективе помогут ускорить разработку. И за полгода со старта проекта сделают на 13% больше работы, чем расширенная собственная команда. Однако обойдётся это недёшево. И если проектов на год и больше, то дешевле расширить собственную команду.

При расширении своего штата полученная «яма» в производительности компенсируется примерно за полгода — то есть новые сотрудники начнут себя окупать.

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

Наблюдение №1: Люди очень редко движутся к своим мечам. Им бы хотелось в принципе эмигрировать в другую страну, совершить кругосветное путешествие, купить загородный дом или феррари. Или, скажем, открыть приют для бездомных собак. Но эти мечты остаются без малейшего движения к ним. Мечты очень редко движут людьми. Впрочем, на то они и мечты.

Наблюдение №2: Люди ставят для себя цели не для того, чтобы чего-то достичь, а для того чтобы УБЕРЕЧЬ себя от каких-то угроз. Это оказалось наиболее интересным «открытием» с точки зрения управления и мотивации. В отличии от мечты, цель предполагает совершение определённых действий в заданном направлении. Люди оценивают цели, декомпозируют и постепенно достигают. Всё выглядит очень круто и здраво. Но когда спрашиваешь, какие именно цели люди перед собой ставят и ПОЧЕМУ, то картина преображается. Мотивом целей чаще всего является избегание угроз, сохранение своей зоны комфорта, и все они как правило далеки от мечт. Например:

- Вася планирует построить дом и переехать жить со своей семьёй. Мотив: городская квартира с достаточной площадью для проживание семьи из 5 человек и пары собак стоит гораздо дороже загородного дома. Цена такой квартиры неподъёмна, а в маленькой квартире все они уже не помещаются.

- Юля учится в институте, и на данный момент у неё цель — написать курсовую работу. Мотив: без неё Юлю выгонят из института.

- В крупной компании ведущий программист Григорий обозначил цель — обеспечить отказоустойчивость системы. Мотив: чтобы меньше попадало от начальства, когда система не выдерживает нагрузки.

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

А о чём мечтаете Вы? И соответствуют ли ваши цели мечтам?

Между тем у меня нет предубеждений на счёт совместимости прекрасного пола и технических профессий. Даже наоборот, по моему опыту женщины программисты работают лучше мужчин. И вот как это проявляется:

• Во-первых, мужчин-программистов на порядки больше, чем женщин. Но если брать отношение достойных работников к количеству бездарностей и лоботрясов, то мужчины проигрывают!
• Мужчины в силу своего мужского начала зачастую преисполнены неоправданными амбициями и завышенной самооценкой. Сильно проявляется фактор соперничества на профессиональном поле. От этого возникают бестолковые споры, «холивары», делёж сферы влияния… Битва за территорию, другими словами.
  У женщин другое поведение от природы. Они не так часто проецируют свои амбиции на профессиональную сферу.
• Женщины не так капризны, как мужчины. Да-да! Именно так! Я встречал многих мужчин-нытиков, которых постоянно что-то не устраивает: рутинные задачи, недостаточно высокий оклад, недостаточное количество развлечений, выбранные технологии и т.д. А женщинам зачастую бывает достаточно похвалы, признания её успехов, банального внимания, чтобы они чувствовали себя в работе просто замечательно.
• Вы не поверите, но женщины, с которыми я работал — ПРОДУКТИВНЕЕ! Вот прямо сейчас одна барышня закрывает вдвое больше задач (по трудозатратам), чем самый производительный мужик в той же команде.

Вы спросите — а как же качество кода? На это я скажу, что надо лучше отбирать кандидатов! И ещё: большая часть «говнокода» написана именно мужиками

Для себя я выявил две причины, почему так происходит:

1. Разработчики делают проекты ради разработки.
   Есть множество интересных проектов, которые никогда не смогут стать бизнесом. Как правило всё начинается со слов «а давайте сделаем социальную сеть!» и заканчивается примерно так «ну и что с того, что никто не пользуется, зато мы сделали это!».  Распространённый случай, детально его описывать не буду.
2. Разработчики делают проекты для IT-шников
   Программисты делают крутое SaaS приложение с перспективной бизнес-моделью. Оно должно стать лучшим на рынке, предлагать массу возможностей, быть гибким и способным удовлетворить любого клиента. И ещё оно должно быть реализовано по последнему слову технологической моды. А проваливается такое чудо-приложение на том, что основная масса целевых пользователей не может в нём разобраться. Парадигмы, предлагаемые модными тенденциями, не близки людям, которые работают с компьютером на уровне «почта-ворд-пасьянс». Они не знают, что такое микроблоггинг или параметрический поиск или интерфейс настройки типа «Wizard». Приложение может и решает проблемы потребителя, но каким-то непривычным и очень «странным» путём, который понятен только искушённым интернет-пользователям.
   В общем получается, что хотели сделать приложение для своей аудитории, а сделали — для конкурентов (чтобы показать им, «какие мы крутые»).

Подводя итог, хочу всем рекомендовать — как можно больше времени потратить на изучение привычек и образа жизни потенциальных клиентов. Как они работают с бумажными документами, как они организуют своё время. Эта информация позволит выявить наиболее важные особенности проектируемого приложения и сделать его максимально удобным для «неподготовленного» пользователя. А это уже половина успеха!

Сегодня я вижу, что справился с большей частью проблем и расскажу, что мне помогло.

Больше всего мне помогло рождение сына. К 2.5 годам это уже маленький электровеник с ядерным ускорителем. И им надо управлять!

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

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

Итак, вот несколько принципов «дрессировки» подчинённых, которые я для себя выработал.

Формулируйте задачи предельно чётко

Чтобы подчинённый делал то, что Вам нужно и так как Вам нужно, не поленитесь ему детально объяснить свои ожидания. Определите требования к качеству поставленной задачи и критерии оценки. Если сэкономить 10 минут на обсуждении при постановке задачи, то в конечном счёте Вы рискуете выкинуть результат недельной работы в помойку. У подчинённого останется неприятный осадок от бессмысленной работы, а Вы «попадёте» на дополнительные трудозатраты.

Хвалите за успехи

Людей нужно хвалить, если они сделали что-то хорошее. Хвалить нужно вслух и искренне. Это даёт два плюса:

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

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

Ругайте за ошибки

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

Подавайте личный пример

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

Соблюдайте дистанцию

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

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

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

Есть, конечно, и другие советы. Их много в специализированной литературе, но такие простые и основательные встречаются редко. Надеюсь, они будут кому-то ещё полезны.

А у Вас есть секреты успешного управления?

А теперь мне бы хотелось поделиться своим опытом: кто такие эти «лучшие» и как их искать.

Структура команды

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

• Человек-паровоз. Это роль лидера в команде. Желательно, чтобы он был достаточно опытен, чтобы лидерские качества подкреплялись практическим авторитетом. Этот человек должен абсолютно разделять цели проекта, он должен верить в успех продукта, который он производит. Если этой веры нет, то его лидерские качества будут только демотивировать команду.
• Человек-вагон. Это роль среднего разработчика, который будет следовать выбранному пути. Он будет писать код в рамках выбранной архитектуры и не будет фантазировать лишнего. Этот разработчик будет мотивирован возможностью получить опыт более зрелых коллег. Но главным критерием остаётся, как и в случае «паровоза», вера в успех продукта.
• Человек-самолёт. Это вообще не разработчик (поэтому уход от метафоры поезда), но очень важное звено в команде. Это роль дизайнера, проектировщика интерфейсов. Он вообще не вникает в низкоуровневые аспекты приложения, парит высоко, мыслит глобально и ориентируется пользователей. Этот человек больше всех должен быть заинтересован в успехе проекта, поскольку результаты его труда станут лицом продукта.

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

Важно соблюсти баланс в команде. Лидеры-творцы должны быть уравновешены исполнительными сотрудниками. Если Вы наберёте только лидеров, то некому будет заниматься рутинными задачами. Также теряется смысл лидерства, если вести за собой некого. Останется только почва для конкуренции. Если брать только исполнителей, то кроме Вас некому будет их воодушевлять и направлять. А у Вас, я думаю, и без того забот хватает.

Ещё раз подчеркну. Каждый член команды должен быть заинтересован в успехе продукта. Это крайне важно для стартапа. Ведь для завоевания рынка потребуется огромное количество энергии, смекалки, инициативы от каждого сотрудника. И как проект будет двигаться, если разработчики будут сидеть сложа руки, пока их не пнёшь? Какой продукт получится, если разработчики плевать хотели на результат, и их заботит только зарплата и уход с работы ровно в 18:00? Думаю, у каждого менеджера есть такой негативный опыт. И я призываю не игнорировать его, ведь на рынке полно молодых классных специалистов с горящими глазами и золотыми руками.

Поиск разработчиков

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

1. Поиск. Постоянный мониторинг сайтов с резюме, размещение вакансий. Первичные коммуникации с людьми. Эту рутину лучше всего поручить вашему HR-менеджеру. Если такого нет, поручите секретарше. Если и это не вариант, отдайте на аутсорс. Выбирая последний вариант, избегайте кадровых агентств. Они неэффективны: пользуются теми же инструментами, что и Вы (сайты по трудоустройству), но берут огромные деньги. На своей 10-летней практике я ни разу не нашёл работу через агентство, только время зря потерял. Для меня это показатель.
   Гораздо проще найти HR-фрилансеров. Конкретных людей, которые знают где и как искать. Они просят меньше денег и более управляемы. Наймите 10 человек с оплатой по тысяче рублей за назначенное собеседование и 10-15 тысяч за принятого на работу.
2. Отсев. В процессе поиска на Вас свалится тонна резюме. Не поленитесь просмотреть каждое и дать ответ HR-менеджеру, почему тот или иной кандидат не подходит. Это позволит сузить поиск и отсеивать заведомо неудачные резюме ещё до того как они попадут к Вам.
3. Собеседования. Заведите общий календарь собеседований. Например в Google. Пусть менеджеры добавляют в него встречи с кандидатами. Вы можете обозначить время, когда Вы не можете проводить собеседования, а остальное — позвольте планировать за Вас.

Собеседование с разработчиком

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

• Реальный опыт и знание технологий;
• Личностные качества;
• Инициативность, мотивированность, заинтересованность в Вашем продукте.

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

1. Попросите рассказать о себе, чем кандидат занимается и чем хочет заниматься.
   При такой постановке человек вынужден кратко и чётко спозиционировать себя и определить свои приоритеты/интересы в предстоящей работе. Чем быстрее и чётче человек ответит на этот вопрос, тем выше его качество мышления.
2. Задайте вопросы из его профессиональной области.
   Если Вы сами не гуру в технических вопросах, привлеките Вашего главного специалиста или внешнего дружественного консультанта. Пусть вопросы будут рассчитаны на более высокий уровень, чем способен ответить кандидат. Нужно заставить его включить мозг на полную.
3. Спросите, чем он занимается в свободное время.
   Этот аспект не менее важен, чем вопросы из профессиональной области. Человек, обладающий высокими личностными качествами, знающий цену времени и деньгами вряд ли станет впустую тратить своё свободное время. У мыслящего человека всегда найдётся интеллектуальное занятие помимо работы — это может быть свой мини-стартап или написание статей, или игра в собственной музыкальной группе.
   Если кандидат к 30 годам ещё не сумел обзавестись семьёй — на мой взгляд, это рождает вопрос к его умению сходиться с людьми, а также к его скрытым личностным качествам, которые могут проявиться позже. Ведь настоящая команда — это почти та же семья, только на работе.
4. Тестовое задание.
   Я обычно даю набор несложных, но «заковыристых» задачек по программированию:
   - Задачи на поиск ошибок в сложном коде,
   - Задачи на поиск оптимального алгоритма решения сложной проблемы (например, выбор случайной записи из таблицы в БД с миллиардом записей),
   - Нетривиальные логические задачи
   Такие задания не требуют написания кода, но позволяют Вам понять, как человек разбирается в технических вопросах, как быстро способен находить решения, а также как он действует в критических и стрессовых ситуациях. Наблюдайте за его поведением — это отражает, как он будет работать над Вашим проектом.
   Если кандидат говорит сразу, что не знает ответа — сразу прощайтесь с ним, ведь он даже не попытался работать головой. Если он не может быстро разобраться в сложном коде, ему тяжело придётся в командной работе над проектом. Если он не обсуждает с Вами решение нетривиальных задач — это опять демонстрирует сложности в командной работе над проблемами.
5. Спросите, что он хочет знать о Вашем проекте.
   Некоторые разработчики осведомляются об уровне заработной платы. Некоторые — об архитектуре Вашего приложения. Реже — о бизнес-модели и целях проекта. Чем больше кандидат задаст вопросов, чем больше обсуждения это вызовет — тем лучше! Это напрямую связано с его заинтересованностью в конечном результате и мотивацией.

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

В завершение статьи хотелось бы упомянуть пару книг, которые укрепили меня в моих взглядах на формирование команды разработчиков стартап-проекта:

• Rework by 37signals
• «Стартап», Гай Кавасаки

Пару лет назад я столкнулся с принципами Agile в относительно крупной разработческой компании. Там декларировались все ценности и номинально практиковались релизы, итерации, скрам-митинги, бек-логи (функциональные требования), демонстрации и т.д. Сейчас я работаю в небольшом стартапе с командой из 4-6 человек, и, опять же, используем принципы Agile.

Сначала кратко расскажу о тех практиках, которые использую и считаю эффективными:

1. Бек-лог (функциональные требования). Проекты бывают большие. Очень большие. Они могут тянуться годами, а обилие функционала способно затмить небо. Как же подступиться к такой мега-задаче? Как оценить трудозатраты на разработку?
   Мы дробим функционал системы на модули, компоненты, группы страниц и т.д. Для каждой компоненты составляем список функциональных требований. Причём требования должен составлять не заказчик, а менеджер от разработки, чтобы эти требования отражали бизнес-логику и были исчерпывающими для разработчиков. Все требования оценивается в условных единицах трудоёмкости, например, в человеко-днях. Таким образом весь проект покрывается списком оценённых требований, и становится приблизительно ясным масштаб «бедствия».
2. Релизы. Требования и компоненты группируются в этапы поставки продукта — релизы.
   Я предпочитаю соотносить релизы с этапами развития продукта:
   1 — Альфа-версия, опытный образец или прототип. Реализует минимально необходимый функционал, отвечающий целям проекта;
   2 — Закрытая бета для внутреннего использования и тестирования
   3 — Открытая бета, доступная для внешнего тестирования, отладки процессов и получения фидбека от первых клиентов;
   4 - Выход в коммерческую эксплуатацию;
   5 и далее — развитие продукта.
3. Итерации. Я предпочитаю недельные итерации, поскольку за неделю бывает реализовано довольно много нового функционала, требующего обсуждения на демонстрациях.
4. Демонстрации. Это очень важный момент в гибких методологиях. Особенность этого мероприятия в том, что заказчик постоянно видит результат работы команды, а команда имеет возможность получать обратную связь — что было сделано хорошо, а что нужно переделать.
   Как правило в ходе этих демонстраций всплывают ошибочные требования, и в режиме мозгового штурма приходят более удачные идеи, чем те, которые планировались в самом начале проекта. Таким образом бек-лог пополняется свежими требованиями, основанными не на предположениях, а на реальном опыте использования ПО.
5. Ретроспективы. В каждой ключевой точке проекта (планирование итерации, демонстрация, релиз) необходимо проводить разбор полётов. Редко когда разработка идёт гладко и все сроки соблюдаются. Так или иначе возникают ошибки, всевозможные проволочки и бестолковая трата времени. И именно регулярное проведение ретроспектив позволяет анализировать ход работы в предыдущем периоде, выявлять проблемы и своевременно их устранять. Важно не превращать этот процесс в порку подчинённых. Разработчики сами должны выявлять факторы, мешающие их работе. А я как руководитель должен устранить эти факторы со всеми своими административными полномочиями.
6. Ежедневные летучки (SCRUM-meetings). Каждое утро команда разработчиков собирается вокруг доски с задачами и каждый обозначает, что было сделано вчера, что будет сделано сегодня, какие есть вопросы и проблемы. Регламент — 15 минут, стоя. Такие короткие митинги позволяют разработчикам постоянно быть в курсе событий, кто чем занимается и получить дельные советы. Ну а у руководителя, таким образом, всё под контролем!

Это тот набор инструментов из арсенала Agile, которыми я пользуюсь. Разумеется, эти практики не могут подойти абсолютно всем ввиду ряда причин, о которых ниже. Сейчас гибкие методологии у меня применяются в небольшой команде и работают из рук вон хорошо! Разработка продукта прозрачна для заказчика. Он всегда видит результат и может своевременно внести коррективы.

Однако в крупной компании все они фатально не работали в 90% случаев! И вот какие факторы препятствовали:

• Внешние заказчики диктовали одновременно сроки и объём работ. Подозреваю, что бюджет тоже. Это были очень крупные и несговорчивые заказчики, имя которых все знают, но я не назову
• Менеджеры продуктов оказывали на разработчиков давление по всем фронтам, используя всю иерархию оргструктуры. В сущности, они не были частью команды, поскольку преследовали другие цели (собственные бизнес-задачи и «прикрыть свой зад»)
• Проектов было очень много, от чего фокус внимания у команды рассеивался. Сложно сконцентрировать внимание и творческий потенциал на разработке нового проекта, когда 50% времени тратится на рутину в виде поддержки старого барахла.
• Бюрократия и неработающие регламенты.  Говорит само за себя.

Такие условия подобно напалму уничтожают почву для открытого обсуждения, новаторства, творчества и производства высококачественных продуктов с удовольствием от работы. Ценность под названием «прикрыть свой зад» начинает доминировать.

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

Не смотря на негативный и даже провальный опыт внедрения Agile, перечисленный набор практик в любом случае очень полезен и в большинстве случаев жизнеспособен. Причём не только в кругах разработчиков, но и во всех смежных областях с разработкой ПО. Важно выбирать с умом те практики, которые БУДУТ эффективны в Вашей компании. По крайней мере они будут полезны Вам как руководителю и Вашей команде, поскольку эти практики способствуют поддержанию тонуса и здоровых отношений.

А используете ли Вы Agile и с каким успехом?