Как правило, большие проекты пишутся не одним программистом. Даже не двумя. Как правило в этом задействована команда. Какие люди туда могут входить? Ну, возьмем схему, когда есть заказчик-инвестор и он находит человека-посредника с командой программистов. Часто эта команда работает удаленно не только относительно заказчика, а и относительно друг друга. И если ребята ответственные и знающие свое дело, все получается нормально. Хотя сдвиг сроков это почти постоянная история в мире программистов (подозреваю что не только в их мире).
Итак, кто же минимально работает над более-менее серьезным проектом? А вот кто:
- Менеджер проекта: отвечает за исполнение перед заказчиком/инвестором, решает финансовые вопросы и осуществляет глобальное планирование и координацию работы команды.
- Бэкенд-программист: отвечает за работу серверного кода, базу данных и внутренние сервисы.
- Фронтенд-программист: на его плечи ложится все то, что мы видим в браузере: HTML-разметка, CSS-стилизация, скрипты, адаптация под различные устройства, кроссбраузерность.
- Дизайнер-проектировщик: без этого человека вряд ли получится нормальный сервис, потому что фронтендер хоть в силу опыта и может спроектировать какой-никакой интерфейс, но гармонично и логически его продумать - далеко не всегда. А проектировщик интерфейсов (обращаю внимание, не просто дизайнер, а именно проектировщик) может все отрисовать логично, красиво и целостно. И тогда уже задача фронтендера перевести нарисованное в формате Photoshop/Illustrator/Sketch/XD (нужное подчеркнуть), в HTML/CSS/JS.
- Тестировщик: исключительно полезный человек, потому что у фронтендера часто "замыливется" глаз и он просто не замечает некоторых багов. Конечно, сейчас пишутся программные тесты, которые "прогоняются" перед каждой, скажем, выкладкой очередного изменения (коммита) в репозиторий с исходниками проекта. Но тестер все равно в сыром коде (а опытный и в достаточно "испеченном"), найдет такие глюки, о которых фронтендер просто и подумать не мог. Он создает такие замысловатые комбинации из действий, которые пользователи непонятно как, но создают.
- Специалист по инфраструктуре: тот человек, который настраивает сервер, устанавливает на него необходимое ПО, разворачивает Docker-контейнеры, если они используются, размещает репозитории с кодом, выдает доступы по SSH, настраивает все с точки зрения сетевой безопасности. Роль такого человека на небольших проектах зачастую выполняет бэкендер.
- Девопс: человек, находящийся на стыке разработки, тестирования и эксплуатации в продакшене. В принципе, можно отнести его к более общему случаю специалиста по инфраструктуре. Он отвечает за переход релизов от разработки/тестирования к эксплуатации в бою. Очень комплексный вопрос, можете об этом почитать в других местах. В маленьких проектах эта роль тоже зачастую ложится на бэкенд-программиста.
- Специалист по безопасности: думаю его задача понятна, но это нередко опускаемый момент, особенно в стартапах с малым финансированием. Можно привлекать на временный подряд со стороны. Скажем, периодическая проверка перед релизом.
Список тех, кто работает над проектом можно продолжать. И чем больше проект, тем больше людей задействовано, тем более узкие задачи они выполняют и тем более актуальным становится вопрос о том, как наладить между всеми ними связь.
Из моего восьмилетнего опыта, могу сказать, что самое важное это терпение, потому что люди попадаются чрезвычайно разные и с общечеловеческой точки зрения они могут быть сложны в общении, но прямо сейчас им замены не найти. Так бывает. На переправе коней не меняют. Так что заранее стоит настроиться на максимально открытый и дружественный лад. Нужно понимать, что задача первее всего, а мелкие склоки можно отодвинуть. Очень помогает личное знакомство вне контекста работы. Когда узнаешь человека поближе, то лучше понимаешь почему он такой и проще оставаться спокойным. Да и человек с противоположной стороны при близком знакомстве может изменить свое поведение в лучшую сторону.
С точки зрения руководителя. Обязательно нужно изучать людей, которые в вашей команде и понимать их психотип. Если есть возможность, то конфликтующих нужно максимально разнести и ограничить их взаимодействие, если это возможно. Если кто-то невыносим, куда бы его не поставили, стоит подумать о том, а нужен ли такой в команде? Возможно нет. И тогда нужно срочно искать ему замену. Либо поговорить с этим человеком "по душАм" и выяснить что не так и как это можно поправить. Главное максимальная искренняя непредвзятость и намерение понять корень проблемы. Все мы люди, а не роботы. У каждого своя личная история и текущая ситуация. Нужно входить в положение и подстраиваться. Если конечно с той стороны явно не пытаются "сесть на шею". Давайте людям кредит доверия, но если они его исчерпали, будьте решительны.
Второй важный момент это организация работы. Постановка задачи должна быть максимально четкой и понятной. Обязательно нужно убеждаться, что исполнитель все понял. Конечно же, должны быть выставлены сроки выполнения (дедлайн). Чтобы вся информация была централизована, используются системы вроде Trello, GitLab или Jira. GitLab мне понравился больше всего, но его нужно установить и настроить. А вот Trello доступен всем и сразу. Функционал простой, для небольших команд то что нужно. И заводить систему контроля задач нужно сразу же, при старте проекта. Иначе, если все будет в чатике или устно, никакого контроля за ходом прогресса не будет. Сроки будут срываться, будет оказываться что люди даже не поняли что та или иная задача висит именно на них. Так что вещь крайне важная.
Следующий момент, это организация структуры. За все должен быть назначен ответственный, чтобы можно было с кого спросить, если что-то пошло не так. По-любому, должен быть координатор проекта, который будет на, скажем так, высоком уровне абстракции докладывать заказчику о ходе прогресса. И этот человек должен быть не лютым зашитым в цифровой мир программером, а коммуникабельным и умеющим просто и ясно донести информацию человеком. Это очень сложная должность, хочу сказать. Плюс этот человек должен осуществлять долгосрочное (стратегическое) и краткосрочное (тактическое) планирование. Потому что нужно знать куда мы хотим прийти через полгода, как можно четче, а уж что мы должны получить к концу недели, надо знать вообще кристально ясно.
Планерки и созвоны важны, но не стоит перебарщивать. Если нечего обсуждать и всем все ясно, то очередной сбор можно и отменить. Поменьше бюрократии и официоза и побольше эффективности. Если кто-то на созвоне не нужен, то пусть занимается делом, а не висит на линии.
Всех нужно обеспечить нормальной связью. В офисе проще - провел хороший интернет и работает, а вот на удаленке у каждого условия свои. У меня бывали случаи, когда до некоторых ребят попросту было не дозвониться из-за ужасного Wi-Fi или еще чего-то подобного. Это крах, особенно когда нужно решить вопрос оперативно.
Да, нужен конечно и общий чат. Slack отличная штука, позволяет все разбить по группам. Программистам вообще там организовано прекрасное прекрасное и плодотворное пространство, но нередко народ общается в Telegram. Он хуже в моем понимании хотя бы потому, что РКН постоянно вставляет палки в колеса и нужно дополнительно заморачиваться с VPN, чтобы подключиться к чату команды. Но тут уж кто как хочет.
Касательно работы над общей кодовой базой. Как показала моя личная практика, разделять фронт одного проекта между несколькими людьми это очень болезненно. На бэкенде это сделать проще. Тут важно найти людей с, опять же, похожим мышлением, чтобы они могли легко договориться о том, как они будут писать код. Они тогда смогут быть друг для друга предсказуемыми и будет минимум ситуаций, когда один на другого ругается за то, какую фигню он наваял и закоммтил. Если один из них более опытный, то разумеется он будет делать код-ревью, то есть глядеть изменениями другого и поправлять их. Если оба равны, то не должно быть момента конкуренции. Должно быть товарищеское отношение. Выяснение таких личных моментов и устранение конфликта также лежит на руководителе команды.
Но для фронта чаще всего стоит оставлять одного человека на одном проекте или его более-менее отдельной части - это проще сделать в наше время торжества микросервисов.
Ну и поговорим еще о зарплате и рабочем дне. Ставка у разных ребят разная. У кого-то почасовая, кто-то работает по фиксу за период. Но если вы работодатель, то знайте, что незакрытые финансовое моменты заставляют специалиста сидеть на иголках и намного хуже делать свою работу. Поэтому в планировании бюджета, выплата ЗП должна стоять на почти первом месте, иначе от вас все разбегутся. Штрафы и прочее это крайняя мера, не стоит тиранить. Все люди, все человеки, разное бывает. Если человек очевидно безответственный, то вопрос понятен, но за каждую мелочь лишать денег это конечно неправильно. Но, по моему опыту, это редкость. В основном команды дружные, понимающие и если надо, то и аванс дадут. Главное выполнять свою работу и быть в умеренной степени проактивным, интересоваться общим ходом проекта и делать максимум что можете.
4 часа в день чистой работы это оптимум, по мне так. Можно и 6, но больше - уже перегруз. Я считаю, что эффективнее будет брать людей на почасовую ставку, а не на фиксированный 8-часовой рабочий день. Бывает так, что перед релизом порой и по 10 часов в день кодишь, но когда ты на почасовой, то понимаешь, что чем больше поработаешь, тем больше получишь. И это честно.
Итог
Я очень коротко и, возможно, сумбурно прошелся по самым, для меня, волнующим и наболевшим моментам, связанным с командной работой над IT-проектами. Тут есть еще много чего недосказанного. Пишите в комментариях, какую тему нужно раскрыть поподробнее и я постараюсь об этом написать все, что знаю. Также, присоединяйтесь к нашему Telegram-чату: http://t.me/makewebme, @makewebme - будем рады интересным и конструктивным обсуждениям.