Доброго времени суток, дорогие гости Хабра!
Меня зовут Роман Мосоло́в, последние 8 лет занимаюсь веб-разработкой. Окончил магистратуру Казанского (Приволжского) федерального университета, факультет программной инженерии. Проектно разрабатывал сервисы для Росатома, Пятерочки, Перекрестка, одной международной CRM и ряда других организаций. В этих проектах выступал как исполнитель, так и был опыт подбора кадров.
Данная статья ориентирована больше для заказчиков. Для тех, кто еще только начинает знакомиться со специфическим понятийным аппаратом разработчиков: фронт, бэк, DevOps и т.п. Хотел бы поделиться некоторыми наблюдениями по поиску программистов для проектов.
Содержание статьи
Статья содержит следующую структуру:
Обратите внимание, что отдельные крупные темы, в частности тема составления технического задания, достаточно обширны, поэтому ввиду преследования нами отличных целей, вероятнее всего, будут рассмотрены в рамках отдельных статей. Также вы можете написать в комментариях к этой статье, о каких именно темах вам было бы интересно изучить более подробный материал.
В рамках материала информацияможет излагаться как в личной, так и в обезличенной форме (с использованием формулировки «мы»). Второй стиль изложения более характерен для научных публикаций и периодически будет использоваться нами, хотя автором материала является только один человек.
Термины и определения
Итак, первым делом предлагаю договориться с вами о терминах и определениях.
Под Системой планирую подразумевать программу любого уровня сложности, начиная от простого скрипта в 10 строк кода и заканчивая наиболее крупными программами в мире, вроде операционной системы Windows, содержащей около 5 млн. строк кода (см. подр. Э. Таненбаум, Т. Остин, «Архитектура компьютера», 6-е изд.). Под этим понятиям мы подразумеваем как веб‑системы, так мобильные приложения и другие виды Систем.
Сопровождение — отдельный, большой этап в жизненном цикле Системы. Когда Система создана, как правило, ее функционал не стоит на месте. У Системы появляются новые пользователи, она дают обратную связь, подсвечивают, какой функционал Системы для них был бы более востребован и т. п. Также на этом этапе неминуемо образуются баги, т.к. появление нового функционала, особенно в сложно связанных функционально Системах, почти всегда приводит к появлению ошибок в работе ранее созданного функционала. Соответственно, на данном этапе становится актуальным всевозможное улучшение функционала Системы. Этап сопровождения в коммерческих проектах обычно занимает значительно больше времени, чем этап разработки Системы.
Этап 1 (определение вида задачи)
Первым делом стоит определиться, какого именно вида задачу вы решаете. Данная статья больше ориентирована на такие виды задач, как разработка новой Системы и сопровождение существующей Системы.
Задачи могут быть самыми разными:
тестирование системы;
парсинг сайта;
SEO-оптимизация сайта (подбор ключевых слов для поднятия сайта наверх в поисковых выдачах Яндекса, Гугла и т.п.);
и т.д.
Этап 2 (ценообразование труда разработчика)
На следующем этапе стоит определиться, какого именно масштаба Систему вы создаете. Напомним, что мы исходим из того, что в первом этапе вас заинтересовали работы, связанные с созданием или сопровождением уже существующей Системы. Данный этап поиска программиста в связи с этим актуален не для всех заказчиков.
На этом этапе вам предстоит понять, над какой именно Системой предстоит проводить работы. Это поможет вам понять, каков будет объем работ и, следовательно, сколько денег нужно заплатить за решение задачи.
Обратите внимание, что без знания средней стоимости часа разработчика стоимость конечных работ можно сильно недооценить. Автору статьи известны случаи, когда доход разработчиков разнился в 23,3 раза, от 30 000 до 700 000 руб/мес. Вопрос стоимости человеко-часа разработчика заслуживает отдельной статьи, в частности рассмотрения в рамках нее факторов, влияющих на ценообразование стоимости труда.
Отметим только вкратце, что на стоимость человеко-часа разработчика могут влиять:
количество проектов в работе (чем больше, тем выше его доход);
наличие зарубежных проектов в работе (они могут оплачиваться раза в 2 выше, чем русскоязычные; это актуально для русскоязычных разработчиков);
квалификация разработчика (доход начинающего специалиста в IT и доход архитектора программного обеспечения могут разниться в 10 раз);
производительность труда специалиста (обычно положительно коррелируют с его квалификацией). Также отчасти зависит от когнитивных навыков специалиста, поскольку они у всех программистов разные.
Этап 3 (определение масштаба задачи)
Задачу (или Систему) по ее масштабности можно разделить на 5 условных классов (по увеличению уровня сложности):
лендинг (одностраничный сайт). Объем работ небольшой (1-5 дней);
Интернет-магазин. Под Интернет-магазином обычно подразумевается сайт с каталогом товаром и со следующим минимальным набором страниц: список товаров, страница товара, Публичная оферта, Политика конфиденциальности и страница добавления новых товаров. Объем работ средний (>1 недели);
корпоративный сайт. Данный сайт тоже можно отнести к классу задач среднего объема трудозатрат. Такой сайт может содержать лендинг некой организации, список ее новостей, контакты разных отделов для связи, страницы с продукцией и направлениями деятельности организации и т.п.;
сервис приложения (или раздел сайта). Под этим понятием обычно подразумевают некоторую смысловую часть Системы. В ряде случаев она может быть зависимой от других частей (сервисов) Системы.
приложение (веб, мобильное, десктоп). Данный класс систем наиболее трудозатратен при разработке среди представленного в данном материале списка задач.
Обратите внимание, что, чем сложнее класс системы, тем сложнее становится оценка трудозатрат на ее разработку. Также стоит отметить, что мы не рассматриваем более специфические виды задач, вроде программирования микроконтроллеров, разработку операционной системы и т.д., предполагая только наиболее распространенные задачи прикладного уровня.
В ряде случаев к виду задачи может относиться также небольшая доработка функционала (программирование т.н. фичи) или исправление ошибки в работе Системы (т.н. баг). Обычно программисты решают от 4 до 8 подобных задач по исправлению багов и внедрению фич за рабочий день. Данный вид задач крайне незначителен по срокам, поэтому мы не будем на нем останавливаться.
Небольшая памятка по срокам
Класс системы | Объем трудозатрат | Срок разработки |
Лендинг | Малый | 1-5 дней |
Интернет-магазин | Средний | 1 неделя-3 месяца |
Корпоративный сайт | Средний | 1 неделя-3 месяца |
Сервис приложения | Большой | 1 неделя-9 месяцев |
Приложение | Большой | 1-2 года |
Если с лендингом объем работ относительно понятен, то с остальными 4 классами дело обстоит сложнее. Основная сложность с Интернет-магазинами и корпоративными сайтами состоит в объеме продвигаемой продукции. Чем ее больше, тем выше вероятность, что скорость отображения данных в Системе впоследствии потребуется улучшать.
Данные по срокам взяты из практики автора. Они являются достаточно условными, т.к. современные коммерческие системы отличаются высокой сложностью и вариативностью в части функциональности. Но эту информацию можно использовать как ориентир для решения ваших задач. Кстати, в расчетах не учитывался этап сопровождения Систем, упомянутый в данном материале выше.
Возможно, вы заметили, что у сервисов приложений может наблюдаться высокая вариативность по срокам. Связано это обычно с количеством внешних интеграций, которые разработчику потребуется вовлекать в процесс разработки. Чем больше внешних интеграций с другими внутренними и внешними сервисами, тем продолжительнее длится разработка сервиса.
С точки зрения заказчика задача подразумевает то, что для разработчиков является большим пластом работ. Поэтому понятие "задача" может разниться в понимании заказчика и разработчика Системы.
Пожалуй, оценка трудозатрат решаемой задачи - это основное, что больше всего выдает малое знакомство заказчика с IT-областью. На биржах фриланса почти повсеместно встречаются задачи, где заказчик ожидает, что всего 1 разработчик разработает за 1 месяц решение, которое в коммерческой разработке обычно делает команда из 5 специалистов в течение целого года. Яркий пример - разработка CRM-системы под ключ. Если у вас задача 2-5 классов объема трудозатрат и вы не уверены в сроке разработки, лучше указывать срок витиевато в описании задачи (вроде "по договоренности") либо явно обозначить в описании задачи, что вы готовы обсуждать сроки. Так исполнителю будет легче откликаться, поскольку неадекватные сроки, почти наверняка, отрицательно скажутся на его рейтинге (будь то биржа фриланса, сарафанное радио и т.п.).
Этап 4 (определение необходимости подключения внешних интеграций)
Итак, вы определились с видом задачи, оценили примерно трудозатраты на разрабатываемый или дорабатываемый функционал. Теперь пришло время понять, будут ли в вашей задаче фигурировать интеграции со внешними системами. Этот этап крайне важен потому, что, как было упомянуто выше, автору довелось поработать в проекте, где вследствие необходимости внешних интеграций и их слабой задокументированности план работ условно в 3 месяца вырос раза в 3 (до 9 месяцев). Если в вашей задаче планируются интеграции со сторонними системами, лучше обозначить это сразу, уже на уровне описания задачи.
Этап 5 (определение технологического стека системы)
Пожалуй, это один из наиболее сложных этапов при решении большой технической задачи для заказчика. От выбора правильного стека технологий сильно зависит то, будет ли впоследствии большое количество желающих для поддержания вашей Системы в работоспособном виде за адекватную стоимость человеко-часа. В сфере IT известны случаи т.н. устаревающих языков программирования, например, ранее широко известный язык Кобол (COBOL), на котором в настоящее время можно найти лишь небольшое количество разработчиков, программирующих на данном языке. Описание этого этапа можно смело пропустить, если ваша Система уже разработана на каком-то стеке.
Здесь можно дать следующие рекомендации: старайтесь выбирать в стек наиболее популярные языки программирования. Существуют всевозможные статьи в Интернете, выходящие по запросам вроде "ТОП языков программирования в XXXX году", где XXXX - год поиска вами специалиста. Таким образом вы можете относительно быстро сориентироваться по текущему состоянию IT-рынка.
Программное обеспечение глобально состоит из 2 основных частей: клиентской и серверной. Клиентскую часть в среде специалистов обычно именуют фронтендом или фронтом, а серверную - бэкендом, или бэком. На 2025 год в разработке клиентской части монополистом является язык программирования JavaScript (сокр. JS). Обратите внимание, что JavaScript в коммерческой разработке в чистом виде (т.н. ванильный, или нативный, JS) используется редко, обычно вместе с ним также упоминается одна из следующих технологий: React.js, Angular.js, Vue.js.
Стоит отметить, что на заре своего появления язык программирования JavaScript был слабо адаптирован к большой коммерческой разработке, в частности в нем отсутствовала т.н. статическая типизация. Данный вид типизации ценен тем, что помогает разработчику предвидеть потенциальные баги задолго до попадания Системы к первым конечным пользователям. В связи с этим, появилась такая технология, как TypeScript (сокр. TS). На 2025 год в большой коммерческой разработке почти невозможно было встретить большой проект, который разрабатывался бы без использования TS. Если специалист предлагает вам разработку на чистом JS без разумного обоснования, это стоит рассматривать как тревожный сигнал, могущий свидетельствовать о недостатке квалификации у специалиста.
Также стоит отметить, что в последние несколько лет распространилось такое понятие, как толстый клиент. Им в среде разработчиков называют Систему, существенная часть логики которой выносится прямо на клиентскую часть. Как следствие такие Системы часто оперируют большими объемами данных, которые сохраняются в браузере пользователя, а затем извлекаются при необходимости. В связи с этим, получили широкое распространение т.н. state manager-ы (или менеджеры состояний). В 2025 году на слуху следующие менеджеры состояний (по убыванию упоминаний в вакансиях фронтенд-разработчиков): Redux, MobX, Zustand.
Разработка клиентской части Системы предполагает программирование ее внешнего вида, т.н. интерфейса Системы. Фронтенд-разработчики, отвечающие за внешний вид Систем, обычно редко создают новые визуальные формы (кнопки, иконки и т.п.) сами, поскольку этом может спокойно увеличить срок разработки новой Системы в 1,5-2 раза, для этого в командах обычно работает отдельный специалист, веб-дизайнер, передающий им для программирования готовые визуальные формы. Однако роскошь содержать в штате веб-дизайнера могут позволить себе немногие компании, чаще всего, это посильно преимущественно корпорациям. В стартапах же, которых на российском рынке большинство, обычно используются готовые визуальные и уже запрограммированные другими программистами визуальные формы. В таких случаях фронтенд-разработчики просто берут их.
Наиболее популярными библиотеками на 2025 года в части готовых форм являются, пожалуй, Ant Design (сокр. antd) и Material UI (сокр. MUI). Для MUI характерны более строгие, корпоративные формы. Для antd более характерны плавные, свободно перетекающие формы. Мы рекомендуем использовать antd, поскольку на 2025 год закругления визуальных форм более характерны для внешнего вида Систем, особенно если вы ориентируете Систему преимущественно под молодежь, обычно хорошо чувствующую подобные нюансы.
А на серверной стороне Систем часто используются PHP, Python, C#, JavaScript (если точнее, серверное окружение Node.js). Безусловно, специалисты в IT-области, читающие этот материал, могут назвать и ряд других языков программирования. Однако для большинства задач человеку, неискушенному в нюансах разработки, обычно вполне достаточно перечня выше. Технологии выше указаны в порядке убывания частоты их упоминаний в Интернете по наблюдениям автора.
На обеих частях Системы может также использоваться ряд других технологий, обычно решающих специфические задачи. Если у вас не узкая задача, а задача, требующая разработки целой системы с 0, то вам вполне достаточно будет выбора технологий из списка выше. Подбор специфических технологий лучше обсудить уже напрямую с потенциальными исполнителями тет-а-тет, дополнительно изучив отзывы по предлагаемым ими решениям в Интернете (исполнителю может быть выгодно предлагать технологию, которая ему привычна, в которой он уверенно себя чувствует; однако на этапе сопровождения Системы может оказаться, что с ней готовы работать немногие специалисты).
Также стоит отметить, что на серверной части Системы почти неминуемо указываются как минимум 2 технологии. Первая обычно характеризует язык программирования, на котором специалист будет работать с логикой Системы, а вторая, как правило, характеризует базу данных, где будут храниться аккумулируемые вашей Системой данные. Здесь по нашим наблюдениям обычно лидирует PostgreSQL. Хотя, безусловно, все зависит от ваших задач. PostgreSQL входит в класс т.н. реляционных систем управления базами данных (сокр. SQL СУБД). Для некоторых задач вам может потребоваться нереляционная СУБД. Если специалист настаивает на определенной технологии, то стоит поинтересоваться, чем обусловлен его выбор. Опытный специалист обычно выбирает технологию по причине ее хорошей адаптированности к решаемой задаче, а не по причине большого опыта работы с ней.
Рекомендуем также обратить внимание на технологию JavaScript, используемую на сервере посредством серверного окружения Node.js. Технология JavaScript примечательна тем, что позволяет, используя всего один язык программирования, разрабатывать сразу и клиентскую, и серверную части Системы. Иными словами, у вас как заказчика появляется возможность работы всего с одним разработчиком, который может разрабатывать и сопровождать вам сразу всю Систему под ключ.
С развитием JavaScript и его адаптацией к серверной логике появилась даже целая плеяда разработчиков нового класса, именуемых фуллстек-разработчиками. Фуллстек-разработчики обычно совмещают как минимум 2 специализации в программировании (фронтенд- и бэкенд-разработчика). В ряде случаев они занимаются также системным администрированием (сокр. DevOps). Отметим, что труд фуллстек-разработчика требует довольно широкой эрудиции об устройстве разных частей Систем, поэтому результат их труда может обходиться на 20% относительно рынка специалистов узкого профиля. Фуллстек-разработчик работает над системой комплексно, что требует от него познаний в области архитектуры программного обеспечения.
Однако, как часто бывает, широкий кругозор часто приводит к поверхностности знаний при глубоком погружении в конкретный аспект разработки. Для небольших систем поверхностность знаний в отдельных специализациях обычно некритична, но если вы создаете большую корпоративную систему, то лучше формировать команду специалистов узкого профиля. Так повышается вероятность, что Система будет разработана на достойном уровне и потребует меньше переписываний кода (читайте: расхода ваших денежных средств) впоследствии, на этапе ее сопровождения.
Итак, если резюмировать, то при создании новой системы, если вы не готовы вникать в тонкости различий между технологиями можно брать за основу один из следующих 2 стеков:
TS (React.js), Redux, Ant Design, Python (Django), PostgreSQL;
TS (React.js), Redux, Ant Design, TS (Nest.js), PostgreSQL.
Этап 6 (составление описания задачи)
Итак, вы определились с видом задачи, определили масштаб Системы, сориентировались по технологическому стеку, предусмотрели возможные внешние интеграции. Теперь пришло время заняться составлением технического задания, или ТЗ.
Частая ошибка заказчиков, наблюдаемая на биржах фриланса, - это неполнота ТЗ. На этом этапе заказчики часто пытаются сократить путь, выдавая всю суть Системы максимум 1-3 абзацами текста. К сожалению, этой информации часто оказывается недостаточно для оценки трудозатрат (объема работ). На этапе, когда вы только знакомитесь с потенциальным исполнителем, для исполнителя немаловажно понять, "во что он ввязывается". Некоторые фриланс-биржи и сами могут не способствовать технически предоставлению подробной информации, устанавливая максимальное ограничение символов на отправляемую исполнителям информацию. В таком случае обычно у вас есть возможность приложения файлов к задаче.
Правильно оценить объем работ исполнитель может преимущественно при предоставлении следующей информации:
список разделов (сервисов) разрабатываемой Системы. Желательно в этом списке также упомянуть, какие разделы относятся к стадии MVP, а какие - нет (т.е. относятся к PostMVP). MVP (англ. Minimum Viable Product) в среде разработчиков Систем означает минимальный жизнеспособный продукт, который будет обладать минимальным функционалом, необходимым для пользователя. Поскольку разные разделы системы обычно различны по технической сложности, упоминание обязательных разделов Системы поможет разработчику грамотнее оценить объем трудозатрат;
макеты страниц Системы. На 2025 год такие макеты обычно предоставляются в формате Figma, реже - как исходники Фотошопа. В них показывают визуальную форму, которую предстоит программировать разработчику. Рекомендуем заказывать разработку только по готовности данных макетов на уровне MVP. Такие макеты полезны как для фронтенд-разработчиков, так и для бэкенд-разработчиков. Первым они помогают оценить техническую сложность визуальных форм, а вторым - оценить степень связанности компонентов внутри системы, оценить объем написания предстоящей бизнес-логики. Если для вас важна точность оценки сроков разработки, то крайне рекомендуем не пренебрегать формированием макетов Системы. При их отсутствии оценка разработки с фактическим результатом может спокойно расходиться в несколько месяцев вследствие того, что разработчик не видел "всей полноты картины". Если Система очень большая, а ее разработка может занять спокойно 1-2 года времени, то предоставить макеты абсолютно всех разделов Системы в таком случае бывает крайне проблематично. В таком случае рекомендуем двигаться от меньшего к большему, трезво оценив свой объем сил. Т.е. как основу отправить макет хотя бы одного сервиса Системы, как средний по затратам шаг отправить макет MVP-сервисов, а идеал - макеты всей Система, включая интерфейс PostMVP;
техническое задание. Идеально, если при заказе Системы вами также будет предоставлено подробное ТЗ. В нем обычно прописывают функциональные и нефункциональные требования к Системе, описывают логику ее работы на естественном языке. Заказчики часто экономят на этом этапе ресурс времени, и это довольно недальновидно, поскольку скорректировать стратегию разработки Системы на бумаге почти всегда дешевле, чем вносить правки непосредственно в программный код. Существуют различные шаблоны для формирования грамотного ТЗ, а также примеры уже заполненных шаблонов других Систем в Интернете. Можно опереться на них, взяв их за основу. Стиль составления ТЗ сильно зависит от вашего характера руководства людьми. Кому-то нравится иметь полный контроль над происходящим, кому-то - предоставлять больше свободы творчества и поощрять инициативу. Мы чаще всего придерживаемся второго стиля управления, поэтому стараемся предоставлять больше свободы разработчикам, но контролировать те аспекты Системы, в которых имеется наиболее высокая цена ошибки. Главное при составлении пунктов ТЗ - помнить, что при недостатке информации разработчики обычно действуют одним из 3 возможных способов: либо просто не реализуют то, о чем не просили; либо реализуют это на свое усмотрение (более характерно для творческих личностей); либо инициируют запрос к заказчику с вопросом, какой реализации он ожидает (более характерно для коммуникабельных разработчиков).
технологический стек. Если Система уже разработана, здесь можно упомянуть текущий технологический стек. Если же стек находится на этапе определения, и разработчик может повлиять на его формирование, то вы можете привести ожидаемый стек, например, из предложенных выше, а затем аккуратно добавить, что допускаете возможность его обоснованной корректировки.
Этап 7 (определение стоимости задачи)
Заказчики и разработчики Систем смотрят на ценообразование их труда несколько различными способами:
позиция заказчика обычно заключается в том, что он хочет увидеть полностью завершенный результат за строго конкретный срок, в идеале без переплат. Обычно заказчик желает услышать сразу конечную стоимость Системы;
позиция разработчика обычно заключается в оценке своего труда помесячно либо за человеко-часы. Разработчик, обычно имея дело только с частью Системы и находясь в зависимости от результатов труда участников своей команды, способен гарантировать точность преимущественно определенных логических частей системы. Например, разработчик может оценить сложность лендинга или сервиса системы. Но оценка трудозатрат для всей Системы обычно по силу только архитектору Системы либо связке ведущий бэкенд-разработчик + ведущий фронтенд-разработчик. Соответственно, разработчики, чаще всего, мыслят категориями оценки труда в человеко-часах.
Мы рекомендуем придерживаться следующих принципов при обсуждении вопроса ценообразования с разработчиком системы (предположительно, с ее архитектором):
проявлять гибкость в вопросе ценообразования, быть готовыми к увеличению бюджета, возможно, даже в несколько раз. Явно обозначать эту готовность на уровне описания задачи;
предоставлять максимум возможных данных (см. предыдущий раздел) на вход разработчику для грамотной оценки стоимости разработки Системы;
запрашивать подробную декомпозицию плана работ. Как минимум с точностью до дня (8 часов), в идеале до получаса-2 часов. Таким образом специалист, проектирующий Систему, вынужден будет достаточно подробно разобраться в деталях Системы. Проектирование крупной Системы с объемом работ на MVP в 1-2 года может потребовать несколько часов времени опытного архитектора. Не каждый согласится проделывать эту работу бесплатно. Рекомендуем выполнение этой задачи оплачивать отдельно. Подробная декомпозиция будет полезна вам в любом случае: во-первых, вы поймете, насколько квалифицирован архитектор, в состоянии ли он удержать в голове устройство вашей Системы; во-вторых, у вас появится первый важный артефакт (результат труда разработчика) вашей Системы - дорожная карта предстоящих работ; в-третьих, у вас появится адекватное представление относительно предстоящих сроков разработки Системы, заказчики на фриланс-биржах довольно часто кратно недооценивают объем технических работ. Дорожная карта пригодится вам даже в том случае, если впоследствии бразды правления по развитию системы, например, на этапе ее сопровождения, перейдут в руки другого архитектора.
Итак, мы рассмотрели в одном из предыдущих разделов, какие сроки бывают при решении разных видов задач. Однако для оценки стоимости работ нам недостает одного важного компонента, знания средней стоимости часа работ специалиста.
Темы обсуждения окладов программистов и популярности отдельных технологий являются достаточно дискуссионными в среде специалистов. Поэтому наши размышления по ним вполне могут оспариваться другими специалистами. Мы лишь поделимся достаточно условными размышлениями по ним, поскольку они раскрывают часть изучаемого нами вопроса (поиска программиста под задачу).
Нами были замечены следующие вилки в оплате труда в зависимости от грейда разработчика (по московскому рынку труда):
Junior-разработчик, 30-60 тыс. руб./мес.;
Middle-разработчик, 100-150 тыс. руб./мес.;
Senior-разработчик, 150-200 тыс. руб./мес.;
ведущий разработчик направления (фронтенд/бэкенд) или фуллстек-разработчик, 200-250 тыс. руб./мес.;
архитектор программного обеспечения, 250+ тыс. руб./мес.
Стоит помнить, что уровни квалификации разработчиков достаточно условны. Нам неизвестно, чтобы в мире имелись какие-то единые международные стандарты, определяющие точный уровень разработчика. Для IT-сферы довольно характерно, когда в одной компании разработчика определяют, например, как Middle-уровня, а в другой готовы доверить ему позицию Senior-уровня.
С разработкой относительно небольших и несложных проектов вам достаточно найти специалиста т.н. Middle-уровня или выше. Этого уровня вполне достаточно для самостоятельной реализации проектов первых 4 классов. А вот 5-й класс Систем (уровень веб-приложения) лучше поручать уже архитектору или фуллстек-разработчику. Эти 2 роли по нашим наблюдениям не всегда пересекаются друг с другом, т.к. фуллстек-разработчик может разрабатывать под ключ обе стороны (фронт и бэк) только одного сервиса. Тогда как архитектор оперирует уже более высокими понятиями уровня веб-приложения.
Этап 8 (необходимость формирования команды программистов)
Отдельным этапом поиска разработчика упомянем такую возможность, как найм сразу целой команды программистов. Подобная потребность появляется не всегда, обычно она тесно связана с масштабом разрабатываемой Системы. Увеличение команды программистов обычно становится актуально при необходимости кратного увеличения скорости разработки новой Системы.
Памятка по увеличению команды разработки
Класс системы | Необходимое кол-во специалистов, чел. |
1 (лендинг) | 1-2 |
2 (Интернет-магазин) | 1-2 |
3 (корпоративный сайт) | 1-2 |
4 (сервис приложения) | 1-2 |
5 (приложение) | 5-10 |
Обратите внимание, что на 5 классе задач команда обычно резко возрастает. Это связано с тем, что приложения могут исчисляться 5-10 сервисами, у особо сложных систем, например уровня CRM, количество сервисов может исчисляться десятками. Заказчики, почти всегда, в таком случае становятся заинтересованы в расширении штата разработки.
Если же говорить про первые 4 класса задач, то в них количество вовлекаемых специалистов сильно зависит от того, решили ли вы работать со специалистами узкого профиля или решили привлекать фуллстек-разработчика. Если решили работать с 2 специалистами, то рекомендуем сначала воспользоваться услугами бэкенд-разработчика, а только затем обращаться к фронтенд-разработчику. Жизненный цикл Систем обычно таков, что первым делом проектируется структура данных под новый сервис и пишется логика обработки и приема этих данных на сервере (часть работ бэкенд-разработчика), а только затем, как правило, программируется пользовательский интерфейс (часть работ фронтенд-разработчика).
Однако здесь есть важный нюанс. Вероятнее всего, после написания серверной логики и ее подключения к клиентской части вам потребуется повторно обратиться к разработчику серверной части. Дело в том, что клиент-серверное взаимодействие часто бывает идеальным с первого раза. Часто на практике приходится иметь дело с тем, что один серверный метод не синхронизирован с работой другого связанного бизнес-логикой серверного метода. Или, например, логика клиентской части написана, но бэкенд-разработчик обнаруживает, что клиентская часть не отображает запрограммированные им ошибки. Рекомендуем дать контакты разработчиков друг другу и не спешить принимать работы, пока обе стороны решаемой задачи не будут готовы. И проговаривать важность этой синхронизации в описании задачи.
Этап 9 (места обитания программистов)
Итак, мы подошли к заключительной части нашего материала. Когда у вас появилось техническое задание (сокр. ТЗ), вы определились со стеком, поняли, сколько специалистов вам потребуется, пришло время определяться с площадкой для размещения информации о вашей задаче.
Можно выделить следующие места выхода на контакт с программистами:
фриланс-биржи. Это хороший способ поиска недорогого специалиста для решения задач 1-4 класса. Такие задачи обычно легче поддаются ограничению по сроку и лучше декомпозируются, чем задача по разработке полноценного приложения;
поисковые системы (фрилансеры, работающие вне бирж). Некоторые фрилансеры со временем обрастают опытом и денежным капиталом, достаточным для открытия своего дела. Это своего рода переходники между специалистами с фриланс-бирж и веб-студиями (см. ниже). Они также могут согласиться поработать с вами, но, вероятнее всего, будут запрашивать гораздо больше за свой труд, чем специалисты с фриланса как минимум потому, что привлечение заказчиков им может обходиться в определенную сумму денег, направляемую на платную рекламу. К ним обычно можно обращаться при любом классе задач;
веб-студии. Этот способ представляет собой т.н. тяжелую артиллерию, когда под ваш проект обычно формируется целая команда специалистов. Могут выделить и только 1 специалиста. Но в любом случае это будет команда, поскольку коммуникация с техническим специалистом, вероятнее всего, будет происходить через менеджера, курирующего ваш проект. Этот способ рекомендуется для задач 5-го класса;
порталы поиска работы. Этот способ тоже представляет собой тяжелую артиллерию. Чаще всего, на порталах поиска работы предполагается занятость минимум на 2 года для программиста. Если вы хотите использовать данный канал для менее продолжительной занятости труда, то рекомендуем обозначить это для специалиста явно, что работа будет непродолжительной. Дело в том, что в сфере IT, по нашим наблюдениям, 2 года - это средний срок, который программист работает на проекте. Многие работодатели отрицательно относятся к краткосрочному опыту пребывания на проектах. Порталы поиска работы хорошо подходят в тех случаях, если у вас новый большой проект (новое приложение) и интересует долгосрочная занятость специалиста, притом вы находитесь еще в самом начале пути его создания;
сарафанное радио. Наконец, всегда можно попробовать найти знакомого программиста, который согласится помочь вам с решением задачи или как минимум порекомендует кого-то из своих знакомых.
Заключение
И вот мы подошли к завершающей части данного материала. Надеемся, данная статья будет для вас полезна и поможет лучше разобраться с устройством IT-рынка, полным множества всевозможных нюансов, не все из которых обычно видны сразу невооруженным глазом.
Благодарим вас за внимание!
