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

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

Часть I. Риски


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

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

  1. Фатальное затягивание сроков. Продукт разрабатывается и даже получается качественным, только вот либо окно возможностей закрылось, либо бюджет закончился.
  2. Стабильно некачественный продукт. Продукт готов и выпущен, клиенты пришли, но они постоянно сталкиваются с проблемами при использовании вашего продукта. А команда неделя за неделей, месяц за месяцем не может обеспечить им нормальную работу. Клиенты не выдерживают и уходят – либо к конкурентам, либо в никуда.
  3. Трудоемкая реализация новых требований. Клиенты стоят в очереди (некоторые – даже с пачкой денег) с просьбами добавить новые возможности, но почему-то доработка происходит очень-очень медленно. Или на серьезных объемах пользовательских данных через год после старта все вдруг стало работать очень-очень медленно, и никто не знает, как быстро решить проблему (а клиенты ругают вас последними словами и уходят). В общем, речь идет о низком «внутреннем качестве» вашего продукта: неудачная архитектура, отсутствие тестов на критические блоки кода, сложные внутренние зависимости – все это не позволяет с приемлемой скоростью развивать продукт и бороться за клиентов.
  4. Потеря работоспособной команды. В какой-то момент ключевые специалисты (особенно, если такой специалист один) могут внезапно решить, что им интереснее работать в другой компании, а то и вовсе попасть под трамвай. Бывает, что оставшаяся команда оказывается не в состоянии не только развивать, но и даже поддерживать продукт с приемлемым качеством. А кандидаты на собеседовании смотрят в полные тоски глаза потенциальных коллег, потом в код, и больше не выходят на связь.


Беда не приходит одна, и часто реализуется сразу несколько рисков. Например, бывает одновременно и фатальное затягивание сроков, и стабильно некачественный продукт, и трудоемкая реализация новых требований. Риск потери работоспособной команды в этом случае вряд ли реализуется, потому что ее тут и не было.

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

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

Часть II. Квалификация и мотивация


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

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

Опишем четыре крайних случая:

  1. Высочайшая квалификация, зашкаливающая мотивация. Это неостановимый Творец. Он эффективен и лаконичен. Всегда знает, что делает, потому что все это уже делал. Работает сутки напролёт, потому что его вставило.
  2. Высочайшая квалификация, мотивация ушла в минус. Тоже всемогущ, только ему ничего не нужно. Кое-как решает срочные задачи, но надо заставлять и контролировать.
  3. Никакой квалификации и никакой мотивации. Стереотипный студент с профильным образованием, который на входе в профессию хочет большую зарплату, но поработать за нее только два месяца в году.
  4. Никакая квалификация, но зашкаливающая мотивация. Человек безумно энергичен, осваивает новое и учится. Но за ваш счет. Совершает всевозможные ошибки, часть из которых проявляется немедленно, а часть выстрелит потом. Пожирает время более опытных коллег (если они есть) вопросами, контролем и исправлением своих ошибок.


Оба эти параметра не постоянны во времени.

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

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

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

Чуть подробнее о квалификации


Квалификацию можно разложить на нескольких составляющих:

  1. Техническая квалификация – это знание своих инструментов (алгоритмов, языков, платформ и сред разработки, кучи фреймворков и библиотек, приложений для работы дизайнера или тестировщика и так далее), а также навыки их эффективного применения.
  2. Опыт – это знание о том, как нужно действовать в тех или иных ситуациях. Его можно получать на своих ошибках (например, когда разработчик сам написал несколько многопоточных приложений и наступил на все основные грабли) или на чужих (например, поработать в команде высоконагруженного решения и вблизи увидеть, как эти ошибки делают другие). Ценность опыта – в возможности на пути к цели избежать ошибок, которые могут дорого обойтись вашему продукту и бизнесу.
  3. Навыки взаимодействия – это умение эффективно выстраивать взаимодействие с окружающими: коллегами, пользователями, клиентами. Сюда входит и умение ясно формулировать мысли, и атмосфера взаимопомощи в команде, и ответственность за качество своей работы, и забота о конечных пользователях, и способность настоять на своем, если потребуется. Такую квалификацию, пожалуй, приобрести труднее всего. Наверное, поэтому ее часто называют культурой.


Чуть подробнее о мотивации


С мотивацией тоже не все так просто. Можно сказать, что у нее есть некоторый базовый уровень, который определяется тем, верит ли человек в продукт, над которым работает, видит ли он перспективы для себя лично, ощущает ли, что в целом все идет, как надо.

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

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

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

Так чего же мы хотим от сотрудников и команды?


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

  1. На все позиции набирать только людей достаточной квалификации;
  2. Обеспечить им высокую базовую мотивацию;
  3. Каждый день контролировать текущую мотивацию.


Часть III. Выбор людей. Правильно и неправильно


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

Как правильно


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

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

Как неправильно


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

У них не будет либо опыта и кругозора, позволяющих принимать правильные решения (например, в части прогнозирования объемов данных, нагрузки, организации модульности и separation of concerns), либо культуры работы в эффективной команде (ответственности, навыков планирования и всякого agile, design and code review, тестирования и написания тестов, и так далее).

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

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

Что бывает за неправильный выбор


Если вы выберете людей без подходящей технической квалификации, то можете обнаружить себя в ситуации, когда вчерашний студент в самом начале выбрал экзотическую СУБД вместо старого доброго SQL, а расходы на сериализацию в JSON оказались такими огромными, что приложение намертво встало. И вот уже три недели команда борется с проблемой устаревания информации в кэше, потому что это все равно быстрее, чем сменить хранилище. И снежный ком проблем продолжает нестись под гору.

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

Особый случай – аутсорсинг разработки


Аутсорсинг разработки – это отличное решение, если ваш стартап провалится.

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

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

Часть IV. Мотивация команды. Правильно и неправильно


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

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

В режиме самореализации человек работает над вашим проектом как над своим. Болеет за проект, поглядывает вперёд, а не только себе под ноги, помогает товарищам. Ну и чего греха таить, хочет втащить новую технологию, опробовать новый подход или переделать все с нуля. Но вообще, в этом состоянии любой член команды в разы продуктивнее, чем в двух остальных (тут мы предлагаем читателю ознакомиться с классическим трудом Фредерика Брукса «Мифический человеко-месяц», если он вдруг еще не знаком с ним). И команда в целом тоже может работать в этаком турборежиме. В этом случае команда даже подтягивает «выпадающих» участников до общего уровня. В определенных пределах, конечно.

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

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

Важно, чтобы команда как можно больше времени проводила в состоянии максимальной продуктивности и ни в коем случае не ушла в минус, откуда вы не сможете ее вытащить. Цена вопроса – шанс попадания в окно возможностей для бизнеса с конкурентоспособным продуктом.

Давайте поймем, как этого добиться.

Как правильно


Наша цель – собрать опытных разработчиков (тестировщиков, дизайнеров, верстальщиков, аналитиков) из крупных и средних IT-компаний, с опытом и высоким уровнем «производственной культуры». А потом поддерживать у них максимально эффективный режим работы.

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

Если вам нужны эти люди, предложите им то, чего не хватает им.

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

Итак, что вы можете предложить вашей будущей команде:

Вовлечение в продукт


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

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

Деньги


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

Вы забираете к себе опытных профессионалов, поэтому зарплата (с учетом премий) должна быть выше рыночной.

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

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

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

Заодно сразу же закроем вопрос о том, нужно ли предлагать долю в бизнесе. Так сложилось, что ситуация в России отличается от ситуации в США в этом вопросе очень сильно. Там стартапы не могут конкурировать в плане денег с крупнейшими компаниями отрасли, зато предлагают мечту – опционы на случай взлёта. У нас все ровно наоборот – стартапы с бюджетом и продуманным планом развития за счет маленькой эффективной команды могут позволить себе платить немного больше рынка. А на обещания доли в светлом будущем никого не купишь: слишком уж печальная статистика. При этом предлагать долю в бизнесе людям, с которыми еще не сварено каши, в России элементарно опасно: корпоративный конфликт на любом этапе может похоронить всё начинание. Опционы же у нас пока толком не работают.


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

Ответственность


Вопрос ответственности – ключевой в разработке программного обеспечения и для команды, и для бизнеса. Если объективно задача требует неделю рабочего времени, а руководитель требует решить ее за два дня и не слушает никаких аргументов, то в 99% случаев результатом будут плохо выполненные требования и горка заметенных под ковёр проблем. Разработчик будет вынужден сделать говно (мы помним, что специально набирали людей, которым делать говно физически неприятно), а проблемы, заметенные под ковер, обойдутся в часы или недели задержек в будущем. Мотивация упала, проблемы появились. Именно поэтому критически важно, чтобы оценка трудозатрат исходила от членов команды. За нее можно торговаться, формулировать задачу более детально, корректировать требования (привет, agile), но окончательную оценку должен дать человек, который будет ее выполнять. Потому что оценка задачи – это акт принятия на себя ответственности за сроки и качество решения этой задачи. Правильность оценки требует опыта, а взятие на себе ответственности требует культуры. Именно эти требования к членам команды мы и сформулировали во второй части статьи.

Ожидания и реальность


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

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

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

Как неправильно


Просто не относитесь к команде разработки как одному из самых ценных активов.

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


Не «отчитывайтесь» перед командой. Ведь если подумать, то какое разработчикам дело до того, как идут продажи? Держите обсуждаемые с клиентами новые функции в секрете от команды до последнего. Заодно всегда в два раза уменьшайте для команды сроки появления функций, которые вы согласовали с клиентами.

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

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

Самое главное в один абзац


Поставьте высокую планку. Набирайте опытных специалистов, умеющих работать в команде. Точно знайте свои финансовые и временные возможности. Продайте команде свой продукт. Обеспечьте хорошие условия. Дайте людям возможность считать продукт вашим общим. Помните, что ответственность – не справка, ее не выдают, а берут своими руками. Следите за ожиданиями и действительностью. Используйте высокую мотивацию команды, чтобы получить конкурентоспособный продукт. И помните, что теперь у вас есть очень ценный актив, который не менее важен и не менее хрупок, чем доверие клиентов и интерес инвесторов.

В следующей части


В следующей статье мы рассмотрим вопросы организации работы команды – тоже с позиции минимизации рисков. Не переключайтесь.
Поделиться с друзьями
-->

Комментарии (22)


  1. Hemdall
    19.05.2016 10:03
    -2

    И не лень вам учебник «менеджмента» конспектировать???


    1. Codenamed
      19.05.2016 10:10
      +1

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


      1. Calc
        19.05.2016 10:25
        +2

        Любая книга др. Деминга
        — Выход из крисиза
        — DAO Toyota
        и т.д.
        Много лет они актуальны, ни один отдел по ним был построен.


        1. Codenamed
          19.05.2016 10:43
          +1

          Упоминаемый в статье Брукс актуален уже несколько десятилетий. Но почему-то каждый год я вижу новые и новые повторения одних тех же ошибок со все теми же печальными последствиями. Ну не читали люди, у которых есть идея и деньги, но которые раньше к разработке не имели отношения, ни Деминга, ни Брукса.

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


    1. Jamon
      19.05.2016 10:22
      +1

      Вот в отличии от учебников — в этой статье сильно чувствуется опыт. То ли потому что это распространенные практики, то ли еще почему то. как то так)


      1. Hemdall
        19.05.2016 10:34
        +1

        Не заметил, что-то тут никакого опыта.

        Собственно полезной информации сверх того, что есть в учебнике =0.


        1. Codenamed
          19.05.2016 11:33

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

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

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


          1. Hemdall
            19.05.2016 12:03

            Не обижайтесь, но точно такого же шлака валом — везде.

            Реальный (пусть минимальный) опыт успешного создания коллектива хоть где — хоть в ресторанном бизнесе, хоть в сервисе, хоть в IT дает умение создавать и поддерживать в активном состоянии коллективы и только этот опыт и интересен.

            Вы сколько коллективов создали и сколько у вас людей под управлением?

            ПС. Заметил странную закономерность — человек только чуть-чуть понявший азы предмета, вдруг начинает своим крошечным пониманием делиться публично со всеми как эксперт, хотя:

            Заголовок спойлера
            Знания без Опыта — ничего не стоят


            1. Codenamed
              19.05.2016 12:48
              -1

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

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

              Что же касается опыта, то у меня есть опыт создания только одной маленькой dream team, которая 1.5 года в отличном темпе выдавала качественный продукт, а потом в одночасье прекратила существовать из-за нескольких описанных в этой статье ошибок.

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


            1. Stas911
              20.05.2016 16:30

              Лучший способ что-то понять — попытаться объяснить это другому…


              1. Codenamed
                20.05.2016 17:08

                Угу, а объяснил пять раз — напиши уже статью на Мегамозг Хабр)


  1. Hemdall
    19.05.2016 13:36

    Самому бы написать, но у меня пока нет свободного времени на качественную статью =)
    Но как только у меня будет настроение и возможность, я накидаю пару страничек по этой теме.

    На тему коллектива и его создания поищите в инете несколько интервью создаля Alibaba — только внимание не на IT, а на опыт создания коллектива и подбора людей. Это — реальная практика в реальном мире а глупые сказки теоретиков.

    Это тоже опыт — вот и опишите как собирали людей, почему они повели себя так и какие были проблемы. Опыт ошибок — бесценен -)

    Любое дело желательно доводить до логического конца бросать это как раз отказываться от опыта…


    1. Codenamed
      19.05.2016 14:39
      +2

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

      Обсуждаемая статья написана, как коммерческое предложение — на определенную целевую аудиторию. Для тех самых людей с деньгам, идеей, но без опыта в IT. Она построена по схеме pain-power-vision-бла-бла-бла и написана так, чтобы нужный человек сперва узнал себя и свою ситуацию, потом примерил на себя риски, которые там перечислены, и уже тогда стал читать про решения.

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


      1. Hemdall
        19.05.2016 16:07
        -1

        =) Люди имеющие деньги не имеют таких проблем потому, что это ошибки периода запуска ПЕРВОГО бизнеса.


        1. Codenamed
          19.05.2016 16:32

          Кажется, у нас с вами очень разный опыт :)


          1. Hemdall
            19.05.2016 18:16
            -1

            Безусловно.


  1. fastwit
    19.05.2016 15:48

    Статья хорошая. Критика в комментариях скорее относится к форме подачи — слегка академической. От этого, видимо, сложилось у читателей ощущение, что это копи-паста прописных истин, хотя кровавый след наболевшего в тексте хорошо чувствуется. Здесь есть нюанс: кому адресована статья? Как мне видится, она адресована не столько даже техническим руководителям (тим-лидам), сколько бизнес-руководителям. Другими словами, чтобы вам не долго и упорно уговаривать и убеждать бизнес-людей в том, что разработка — это не дрова колоть, а просто дать ссылку. Ведь, согласитесь, сложно владельца бизнеса заставить прочитать и понять Брукса, я уже не говорю о других классических трудах.
    Вот мой список прописных истин по теме, помимо Брукса:
    1. Steve McConnell. Software Estimation: Demystifying the Black Art. — Очень интересные мысли о бюджетировании проекта и расчете сроков.
    2. J. Hank Rainwater. Herding Cats: A Primer for Programmers Who Lead Programmers. — Интересное мнение о психологии разработчиков и лидировании команды.
    3. Larry L. Constantine. The Peopleware Papers: Notes on the Human Side of Software
    4. Tom DeMarco. Peopleware: Productive Projects and Teams
    5. Alan W. Brown. Enterprise Software Delivery: Bringing Agility and Efficiency to the Global Software Supply Chain. Интересные мысли про аутсорс.
    6. Rahul Goyal. Management in India: Grow from an Accidental to a successful manager in the IT & knowledge industry. — Тут и про аутсорс, и про мотивацию и вообще интересно «как там у них».
    7. Jessica Keys. Leading IT Projects: The IT Manager's Guide. — Очень много про подбор команды, мотивацию команды, управления рисками, связанными с командой и вообще про то как «не сесть в лужу лицом».
    8. Jey Leibowitz. Knowledge Retention: Strategies and Solutions. — Если у вас софтверная компания или просто большой и важный проект и вы боитесь текучки, а также того, что есть один «золотой» человек, который все знает — эта книга просто обязательна к прочтению.
    9. Cynthia Snyder. PMP Certification All-in-one for Dummies. — Если лень или надо очень быстро войти в тему управления проектами и в частности как правильно готовить команду, то книга поможет это сделать.
    10. Рекомендую прочитать книги Peter F. Drucker, есть также несметное число книг про Agile где также вы всегда найдете упор на команду.


    1. Codenamed
      19.05.2016 16:00

      Да, так и есть. Статья для людей, которые пришли в IT делать бизнес и со всеми особенностями отрасли не знакомы. ДеМарко я тоже настойчиво рекомендовал к прочтению, вместе с Бруксом. Даже в свое время хотел купить десяток Peopleware в мягкой обложке и раздавать в подарок, но они тогда пропали из магазинов почему-то :)


  1. Fen1kz
    20.05.2016 14:42
    +2

    Про квалификацию бред какой-то. Зачем описывать крайние случаи, если таковых не встречается? "Никакая квалификация, но зашкаливающая мотивация." — ни слова о том что чувак изговнокодит весь проект.


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


    1. Codenamed
      20.05.2016 15:06
      -1

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

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

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


      1. Fen1kz
        20.05.2016 15:34

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

        Так вот нет, ошибки исправляются, а вот кашархитектура требуют переписывания компонента. Или чаще все забивают и на такой архитектуре пытаются что-то сделать. Это нельзхя назвать "выстрелит потом"


        советы не такие уж очевидные,

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


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


        1. Codenamed
          20.05.2016 16:48

          https://habrahabr.ru/post/301148/#comment_9616396