Как собрать команду разработчиков приложения

Обновлено: 07.01.2025

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

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

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

Где искать команду

Сегодня существует множество различных способов поиска IT специалистов, начиная от простейшего “сарафанного радио” и заканчивая специализированными веб-сайтами.

1. На специализированных площадках

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

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

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

Umbrella IT советует использовать для поиска команды площадку Upwork, где большой выбор специалистов, понятен и легок процесс поиска, коммуникации и работы с ними. Чтобы начать работу:

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

2. В Google-поиске

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

Например, вы можете использовать такие:

• профессиональная команда разработчиков
• команда разработчиков сайтов с портфолио
• мобильная разработка приложений для ios/Android
• профессиональная разработка продающих сайтов
• разработка мобильных приложений на заказ
• создание веб проекта для % спецификация нашего проекта %

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

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

3. На LinkedIn

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

Как же найти команду разработчиков на LinkedIn?

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

4. У друзей

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

Поэтому вспомните, кто из ваших друзей или знакомых делал стартап или каким-то образом связан с IT сферой и напишете им:

"Привет! Я сейчас ищу хороших разработчиков для реализации веб (мобильного) проекта. Ты бы мог кого-то посоветовать? "

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

5. В стартап-инкубаторах

Стартап-инкубаторы – это еще один отличный ресурс для поиска опытной и сильной команды разработчиков.

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

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

6. В социальных сетях

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

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

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

Заходите в различные группы, посвященные разработке веб и мобильных проектов, и оставляете по аналогии вышеприведенного способа свои объявления.

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

Критерии отбора

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

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

Итак, обращайте внимание на:

• ГОД ОСНОВАНИЯ КОМПАНИИ. Вы хотите быть уверенными, что разработка вашего проекта не остановится на середине из-за внутренних проблем и трудностей компании разработчиков.

Поэтому вы не должны рассматривать компании, существующие на IT рынке менее 3х лет, поскольку вы не можете быть уверены в их стабильной работе.

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

• РАЗМЕР КОМПАНИИ. Вы хотите, чтобы ваш проект развивался стабильно и согласно намеченному плану, поэтому, чем больше команда разработчиков, тем лучше. Н е стоит делать выбор в пользу компании со штатом менее 15 человек, если только все они не будут работать над вашим проектом.

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

• ПОРТФОЛИО. Всегда внимательно изучайте портфолио потенциальных исполнителей, чтобы удостовериться, что по окончании работы вы получите свой проект именно таким, как вы его задумали.

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

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

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

Как принять решение

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

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

При этом стоит помнить, что:

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

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

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

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

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

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

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

Так было и в моем случае: я удаленно вел несколько проектов для зарубежных компаний и собирался вновь зимовать в Таиланде, когда со мной связался Евгений Лобанов. Мы вместе работали в другой компании. Там начинался мой путь руководителя мобильной разработки. Мы не теряли связь все эти годы, пока я делал продукты и собирал команды на различных проектах. К тому же я знал еще несколько сильных специалистов, работающих в AGIMA, поэтому над предложением о работе в компании я задумался всерьез. История оказалась следующей: в четвертом квартале 2017 года компания начала реструктуризировать свой мобильный продакшн.

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

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

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

Турбо-рекрутинг

Необходимый состав команды:

15 топ-менеджеров , которые вывели свои компании на лидирующие позиции в рейтинге ESG.

• Ряд технически подкованных тимлидов
• Отряд разработчиков
• Мобильные дизайнеры
• Тестировщики

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

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

Наш HR-отдел ежедневно контактировал с десятками специалистов на онлайн- и офлайн-площадках. Мы внедрили своих агентов на четыре ключевых мероприятия по мобильной разработке: Mobius, Российский интернет-форум, MBLT и Target Summit. Там мы получили доступ к резюме, которые нельзя найти онлайн. Количество кандидатов было таким, что в течение 3-х месяцев мы проводили по 3-5 встреч с кандидатами ежедневно, что в итоге составило рекордные 334 собеседования. Мы смогли достичь этих показателей благодаря тому, что вовремя обратили внимание на регионы России и страны СНГ, где разработчики успели привыкнуть к работе по интернету. Мы же предлагали им релокейт и постоянное трудоустройство.

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

• Телефонный опрос по стеку технологий
• Опросник
• Техническое интервью
• Разыгрывание реального кейса кризисной ситуации

Каждый из этапов дает определенный срез технических навыков и отсеивает от 70 до 89% кандидатов. При этом все этапы, кроме тестирования, встроены в ткань интервью так, что кандидат не всегда замечает момент, когда именно его начинают тестировать.

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

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

Новые звезды

С самого начала я ставил на супергероев, которые умеют делать все и смогут быстро решить львиную долю технических задач. Для этого мы сперва провели свыше 80 интервью с самыми сильными тимлидами, которых смогли найти, и ситуация с ними слегка удивила. Если раньше востребованность мобильных разработчиков определялась их отсутствием на рынке, то сейчас спрос стал еще выше из-за того, что лидеры индустрии разобрали немногих специалистов, необоснованно завышая зарплаты.

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

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

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

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

• Демонстрируют достаточно высокие технические навыки
• Имеют хорошие софтскиллз
• Адекватно смотрят на свой уровень
• Хотят развиваться

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

Итоговая команда и бюджет

В итоге мы собрали такую по составу команду:

• 4 тимлида на iOS и Android
• 11 разработчиков
• 2 backend тимлида на Python
• 3 UX-дизайнера
• 6 QA-инженеров
• Руководитель мобильного дизайна — Леонид Никулин
• Руководитель мобильной разработки — Дмитрий Шашлов

За 3 месяца мы получили 28 крутых специалистов. Стоимость такой команды — 3 870 000 рублей в месяц. В итоге эта сумма существенно не превысила для нас стоимость нашей прежней удаленной команды, но теперь мы имеем качественную разработку внутри. За эти три месяца мы совокупно отправили на релиз 62 сборки по всем нашим проектам.

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

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

Советы от hr-менеджера компании Артема Лапина

• Пишите о продукте. Для внешнего наблюдателя сложно отличить одно агентство от другого. Поэтому пишите о продуктах, которые вы разрабатываете для своих клиентов — будущему разработчику будет легче определиться, если он будет понимать, над чем придется работать.
• Опишите возможности роста. То, чего недостает многим предложениям на рынке заказной разработки. Если вы собираете новую команду, расскажите о карьерных возможностях, которые есть у сотрудников, которые войдут в основу. В нашем случае мы обсуждали с кандидатами их индивидуальные планы развития в компании и на проектах, что сильно раскрепостило новых ребят уже во время испытательного срока.
• Отличайтесь. Большинство студий не обращает внимание на то, что их вакансии повторяют вакансии конкурентов. Ваш подход должен отличаться бОльшим вниманием к интересам кандидата. Будет здорово, если вы сможете выразить дух компании через ваше обращение. Мы, например, сделали социальную рекламу о проблемах мобильных разработчиков. Ролик был сделан в самом начале кампании и не принес нам откликов, зато помог быстро понять необходимость изменения изначальной стратегии.
• Теплый прием. Проведите аудит проекта и удостоверьтесь, что код достаточно задокументирован, бэклог задач понятен, имеются все требования и спецификации. Нередко команды, пишущие с нуля, пренебрегают такими процедурами, поскольку отлично знают проект. Но зато ваши новые сотрудники смогут мгновенно сориентироваться в проекте и приступить к работе.
• Релокейт и регионы. Не забывайте настроить свою рекламу, вакансии и рекрутеров на поиски региональных специалистов. Это важнейший источник перспективных кадров с ясной мотивацией делать качественный продукт. Мы взяли себе в команду несколько таких разработчиков, помогли организовать переезд и оформить для иностранцев документы, необходимые для работы в России. Мы также помогли решить проблему со съемом жилья, оплатив для них 50% аренды на первые месяцы.

Результаты

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

Кроме того, за эти три месяца мы не только набрали команду из 28 человек, но и выкатили несколько новых мобильных приложений: «Мой Перекресток», «Тануки», «Дом.ру» и «Пятерочка».

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

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

Шаг 0. А нужна ли инхаус-команда?

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

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

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

Шаг 1. Начинайте не с разработчика

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

Шаг 2. Определите список ролей и подготовьте описание вакансии

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

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

Вот пример структуры описания роли, которую можно использовать:

• Название роли.
• Описание задач.
• Портрет человека, которого вы ищите.
• Формальные требования: какие нужны технологии и опыт.
• Описание проекта и команды.

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

Первый экран страницы с описанием вакансии дизайнера. Тут название, описание, список технологий и условия. Ниже на странице — более подробная информация о нас

Шаг 3. Выберите потенциальных членов команды

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

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

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

Шаг 4. Организуйте тестовый день или испытательный срок

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

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

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

Шаг 5. Стройте процессы в команде

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

👉🏻 Система регулярного менеджмента. Например, можно работать спринтами. В начале каждого определять цель на ближайшее время, ставить и декомпозировать задачи. Проводить ежедневные статус-митинги. В конце спринта организовывать ретроспективу и демо: обсуждать, что сделали, что получилось, какие возникли проблемы. Давать регулярную обратную связь.

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

👉🏻 Организация технических процессов. Техническому лидеру команды стоит заняться тем, что разработка стала постоянным конвейером. Для этого должны появиться процессы тестирования, отдельные контуры для разработчиков, автоматизированные системы публикации обновлений.

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

👉🏻 Синхронная работа разных команд. Со временем проект может разрастись и специалисты начнут работать обособленно: разработчики, дизайнеры и аналитики будут закрывать задачи отдельными командами. В этом случае нужно убедиться, что их работа удачно стыкуется. Например, дизайнеры обычно идут на 1–2 спринта впереди разработчиков, чтобы к тому моменту, когда задача попадает в работу, для неё уже были готовы макеты.

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

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

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

Иногда может показаться, что команда разработчиков, с которой вы работаете, говорит на другом языке 😅 Они называют людей непонятными аббревиатурами, вроде PO, PM, PMM, и обсуждают Agile, Kanban и Scrum. Без паники, сейчас мы расскажем, что это значит! В Purrweb мы занимаемся разработкой программного обеспечения с 2014 года. На протяжении этого времени мы экспериментировали с ролями в команде и пробовали несколько способов коммуникации, до тех пор пока не нашли то, что подходит именно нам. В этой статье мы поделимся своим опытом организации команды разработчиков и расскажем, какие роли существуют в IT команде. Вы узнаете, на что обращать внимание при аутсорсинге разработки программного обеспечения, и как собрать команду и избежать основных ошибок. Поехали!

Время чтения: 6 минут

3 типа команд в Agile: универсалы, специалисты и гибридная команда

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

В идеальном мире Agile-подхода у команд существует 3 типа структуры — рассказываем про каждую отдельно.

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

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

Специалисты

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

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

Гибридная команда

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

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

Как это работает в Purrweb

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

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

Какие бывают роли в IT-командах

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

Вот классический набор:

• владелец продукта
• проектный менеджер
• аккаунт-менеджер
• UI/UX дизайнеры
• разработчики
• QA инженеры

Владелец продукта (product owner, PO)

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

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

Аккаунт-менеджер

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

Проектный менеджер (project manager, PM)

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

Если вы слышите, как кто-то кричит: «Нам нужно ускориться», «Давайте сначала просчитаем риски», «Что-то работает не так», — вероятно, проджект-менеджер где-то близко.

UI/UX дизайнеры

Эта часть команды просыпается утром и сразу думает о пользователе. Она подключается к разработке программного обеспечени я на ранних этапах и следит, чтобы все в приложении было простым и понятным. Им помогают UI/UX копирайтеры, которые следят за текстом в решении и знают, как уместить важное объявление в push-уведомление, чтобы его открыли и прочитали.

Разработчики

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

QA инженеры

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

READ MORE UX дизайн и жажда получить $1,000,000 из крипты. Кейс Purrweb

Как это работает в Purrweb

На пути к идеальной структуре мы сделали несколько ошибок и многому научились. Этот опыт помог нам узнать больше об управлении процессами разработки и разграничивать роли в IT-команде .

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

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

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

У разработчиков Purrweb тоже есть свои правила: в их команде есть тимлид, который отвечает за управление процессом разработки и контролирует промежуточные результаты. Кроме того, мы предпочитаем сами обучать новичков работать с фулстеком 😈.

READ MORE Кейс экспресс-дизайна от агентства Purrweb: как упаковать медицинский стартап за $1500 и привлечь $400 тысяч

Как понять, что перед вами эффективная организация команды разработчиков?

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

При аутсорсинге разработки программного обеспечения следует обратить внимание на несколько вещей:

• Налажена ли у них коммуникация? Посмотрите, как члены команды общаются между собой. Да, программисты не роботы и столкновения на рабочем месте неизбежны, даже при разработке программного обеспечения . Но в здоровых, хорошо организованных командах есть инструменты, как договариваться и разрешать конфликты. Можно сразу спросить: «Ребята, а как вы коммуницируете между собой? Какие приложения используете, чтобы оставаться в курсе рабочего процесса?». Если вам расскажут про Slack, Jira и Targetprocess — направление уже верное.
• Как они распределяют рабочие роли? Главное правило хорошей Agile-команды — отсутствие хаоса. Процесс разработки программного обеспечения должен быть структурирован, а каждый участник — знать, что он должен делать и к кому обращаться за советами. Чтобы проверить, как это устроено, вы можете просто спросить команду, как выглядит их рабочий процесс, кто отвечает за каждый шаг и кому вы можете задать вопрос о промежуточных результатах.

• Есть ли у них общие цели? Большинству Agile-команд не нужны четкая иерархия и строгий контроль, потому что у них общие цели и они знают, ради чего работают каждый день. Например, в Purrweb наша цель — помочь стартапам быстро проверить свои бизнес-идеи, и если вы спросите кого-либо из нашей 100 членов команды, они скажут вам тоже самое.
• Могут ли они быть независимыми? При разработке программного обеспечения строгий надзор не приносит никакой пользы ни клиенту, ни команде. Чтобы следить за каждым движением, со стороны заказчика потребуется много времени, которого у стартаперов обычно нет. А для команд пристальный контроль может демотивировать и мешать креативности. В общем, хорошая команда должна уметь работать независимо, чтобы вам не приходилось тратить все силы на управление процессами разработки .

READ MORE Музыкальный маркетплейс для автора голливудских трейлеров. Или как помочь клиенту зайти в конкурентную нишу. Кейс Purrweb

Итоги

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

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

Хотите познакомиться с нашей командой и получить помощь в проверке идеи для вашего стартапа? Напишите нам!

Читайте также:

  
• Не удалось установить приложение play market повторите попытку
  
• Как разрешить приложению доступ в интернет
  
• Статистика использования приложений андроид
  
• Как посмотреть свой профиль в whatsapp
  
• Приложение для оплаты через nfc iphone