Азбука стартапера. Управление разработкой и разработчиками.

Глава «Управление разработкой и разработчиками» из Азбуки стартапера (In progress)

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

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

Итак, в технологиях вы разбираетесь (либо разбирается ваш технический кофаундер). Что дальше? Набираем разработчиков. В идеале единственный разработчик до момента выхода проекта на самоокупаемость — ваш технический кофаундер. Лучше дать хорошую долю и/или вознаграждение одному крутому специалисту, чем брать трех посредственных. С одним хорошо мотивированным компетентным специалистом работать проще, чем с командой наемников — он сам предложит оптимальные решения, будет работать эффективно на результат в постоянном контакте с вами.
Кстати, я знаю одного такого специалиста 😉

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

Какие разработчики нужны?

Базовых три вещи:
— уровень компетенции
— личные качества
— готовность работать по вашим условиям

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

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

  • Обратная связь. Возможно, самое главное качество. Я ожидаю, что разработчик будет высказывать свое мнение, задавать уточняющие вопросы, предлагать свое решение задач, сообщать о возможных проблемах.
  • Соблюдение сроков. То есть разработчик должен стремиться к выполнению задач точно в срок. А если это по каким-то причинам не получается, сразу же сообщить об этом.
  • Адекватность в оценке своей компетенции. Разработчик должен признаться, что он плохо разбирается в каких-то вопросах, а не молча пытаться грызть сложную задачу, наступая на грабли и затягивая время.
  • Желание повышать свои компетенции, учиться новым вещам.
  • Мотивация не только на деньги. Хорошие варианты мотивации: профессиональный рост, желание усилить свое портфолио, интересная по содержанию работа, быть круче коллег, чувствовать значение своей работы в общем результате и др.

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

 


 

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

Вот несколько шагов, которые могут повысить эффективность работы:

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

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

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

3. Организовать взаимодействие между членами команды

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

Ваша задача — обеспечить плодотворное сотрудничество между членами команды. Должно быть нормальное неформальное общение без отвлечения на сторонние темы.

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

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

4. Делайту оценку затрат времени на задачу

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

Зато такое планирование дает ряд преимуществ:
— вы откидываете задачи, которые отнимут много времени или находите другие пути решения
— вы понимаете, что больше всего может задержать график работ. Часто это совсем не критические для проекта вещи
— вы контролируете разработчиков. Если разработчик за день сделал только одну часовую задачу, это повод разобраться
— вы лучше понимаете квалификацию ваших разработчиков. Если ваш разработчик делает задачу за четыре часа, а сторонний разработчик за час, то может лучше нанять стороннего разработчика, хотя он и стоит в два раза больше?

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

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

5. Мотивируйте разработчиков на качественное выполнение работы в срок

Зарплата в виде ставки не слишком мотивирует кого бы то ни было на эффективную работу. Штрафы и премии влияют на это гораздо больше. У вас должна быть возможность гибко устанавливать вознаграждение. В самом простом виде хотя бы премия в 1тыс.руб. за плодотворную неделю без косяков.

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

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

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