«Кто должен писать ТЗ»
До момента отвоза заказа, нам нужно разобраться с одним важным моментом: а кто же должен писать ТЗ? — Этим может заниматься один человек — аналитик-проектировщик. И проблема с ними одна — их очень мало на рынке, на них нигде не обучают. И я уже как Мастер Йода изыскивал несколько человек. Они получаются случайным образом.
Человек получает техническое или около-техническое образование, и дальше "мотыляется" по рынку, работает дизайнером, сеошником, верстальщиком, маркетологом, пока в какой-то момент он не оказывается в точке, где человек ему говорит: «Хочешь стать аналитиком-проектировщиком?»
— Хочу, а что это такое?
— Сейчас расскажем!
И через месяц выясняется, что человек всю жизнь этого ждал. И он начинает работать, он загорается. Сейчас я вкратце описал биографию свою и всех тех, кого я приводил. И когда я впервые получил тестовое задание и просидел над ним с 10 вечера для 4 утра, то для меня это время пролетело, как один миг. Я понял, что да, наверное, это хорошая работа для меня.
На рынке таких специалистов мало, их не генерируют, их добывают по крупицам. Но для работы достаточно несколько человек, которые будут отвечать за общее видение, и будут такой закваской, будут team-лидами.
Остальные все вещи очень хорошо делегируются. Например можно взять аналитика. Этих ребят на рынке много. Во многих университетах готовят по специальности системных аналитиков много специалистов, они хорошо работают, умеют анализировать бизнес-требования, работать с пользовательскими требованиями и всё это документировать.
Единственное — они не умеют проектировать, и поэтому они не могут сделать следующий шаг, — «сгенерить». Но на это мы можем найти отдельных людей — проектировщиков.
Проектировщики обычно получаются или из дизайнеров, которые всю жизнь мечтали стать инженерами, или из инженерами, которые всю жизнь мечтали стать дизайнерами. — Это ребята, которые могут получить какие-то аналитические данные, уложить их в понятный интерфейс, просчитать какую-то общую архитектуру проекта, и при необходимости написать к этому техническое задание.
Мы можем дробить на самом деле всё это и дальше, — до того, что отдельный человек сидит с клиентом — общается по бизнес-требованиям. Но чем больше мы дробим людей, тем сложнее масштабировать нагрузку, и эта история начинает работать только при каком-то колоссальной загрузке на всех специалистов.
И к этой схеме рынок рано или поздно придёт. Но пока для нас всех, я думаю, достаточно начать искать, формировать аналитиков-проектировщиков, хотя бы отдельно аналитиков, отдельно проектировщиков, чтобы система заработала.
Интересный момент — когда мы берём аналитика-проектировщика, он занимает очень интересную позицию в разработке. Так как он начинает рубится крепко за качественный продукт, он начинает играть роль некоего адвоката продукта. Причём адвоката — как перед клиентом, так и перед разработчиком.
И аналитик может в какой-то момент выделить третью силу, которая может начинать вставлять палки в колёса и клиенту, когда клиент начинает "генерить" что-то, что повредит продукту.
Причём говорить это обоснованно — типа «Нет, так делать нельзя, потому что...», так и перед разработчиком, когда тот хочет срезать угол и сказать: «Давайте эту интеграцию отменим, давайте просто на вёрстке это нарисуем, всё равно заказчик не заметит».
Аналитик скажет: « — Нет, продукт должен быть качественным, должен быть цельным, мы всё прописали, оно должно работать.»