Даже самому заядлому гуманитарию нужно погрузиться в IT-контекст, чтобы общаться с программистами и разработчиками на одном языке: формулировать задания, задавать вопросы, контролировать процесс, оценивать их предложения и выполненную работу. А иначе — недопонимания, переделки и перерасход бюджета.
Вместе с Денисом Дубовсковым, фаундером IT-компании Orange DM, разбираем самые употребимые термины и объясняем, как их применять. Практическую часть отметили таким эмодзи👉.
Базовые термины для разработки
API или «апи». Это протокол, по которому общаются разные информационные системы. Вот возьмём сайт и онлайн-кассу — они не могут связаться напрямую, потому что у них отличаются внутренний язык и правила. API в этом случае — как переводчик: он «говорит» сайту, как правильно отправить запрос, и «объясняет» кассе, что от неё хотят. Благодаря нему системы понимают, как запрашивать данные друг у друга, и устанавливают соединение.
👉 На старте проекта выясните, умеет ли система отдавать данные по API. Если нет, стоимость проекта может вырасти в несколько раз. В худшем случае окажется, что интеграция невозможна.
Мы привыкли, что у популярных CRM вроде Битрикс24 все протоколы открыты и отлично взаимодействуют с сайтами. Но так не везде. Например, в некоторых медицинских системах часть данных закрыта, и её не передать по API.
Мы собирали для клиента медицинскую информационную систему. Перед началом работы мы не проверили, может ли система делиться данными по API. Только в процессе работы поняли, что не получается подружить стоматологическую CRM с нашим IT-продуктом. Могли бы решить вопрос другими способами. Например, через кучу сложного кода. Но тогда бы выросла цена. В итоге, мы отказались от проекта и потеряли деньги. Такие нюансы лучше обсуждать до старта.
Framework или «фреймворк». Это готовый каркас для будущей программы: кто-то собрал архитектуру и разложил всё по полочкам. Например, популярный в разработке фреймворк — Laravel. Он даёт готовые инструменты и делает код лаконичным. Программист берёт его за основу и создаёт свои веб-приложения и сайты.
Плюс популярного фреймворка — на него легко найти исполнителей: если команда разбежалась, другие разработчики зайдут и разберутся. А вот если клиенту написали всё с нуля, на своей кастомной архитектуре — он привязан к этой команде. Другие просто не возьмутся. Или попросят очень много денег.
👉 Разберитесь, какой именно «фреймворк» разработчик планирует взять. Выбирайте популярные фреймворки, чтобы позже легко масштабировать проект. А если предлагают малоизвестный или самописный фреймворк, разберитесь, точно ли нужен именно такой и почему.
Pipeline или «пайплайн». С английского — конвейер. В IT-сфере — последовательность этапов бизнес-процесса от начала и до результата по определённому маршруту. В разработке — это путь от идеи до запуска. В продажах — от лида до оплаты. Когда пайплайн выстроен, скорость работы кратно увеличивается. Когда его нет — каждый раз всё делается заново и по-разному.
👉 Попросите у команды показать пайплайн. Они сразу поймут, что вам нужна система, маршрут, логика от точки А до точки Б. Не набор действий, а выстроенный процесс.
Основные процессы
Backlog или «бэклог». Это копилка всех идей и задач, которые компания хочет реализовать, но пока не берёт в работу. В бэклоге копятся идеи, которые пришли в голову в разговоре с заказчиком или командой. Позже специалист, который распределяет задачи, зайдёт в эту копилку, выберет нужное и раскидает по спринту.
Если бэклог не чистить и не структурировать, он превратится в свалку из задач, где непонятно, что актуально, а что уже неважно.
👉 Слово выручает, когда к вам приходят с идеями не вовремя. Когда вы говорите: «Отлично, кладём в бэклог» — вы не отметаете идею и не берёте её в работу прямо сейчас. Действует в обе стороны: если подрядчик говорит «положим в бэклог», значит услышал и позже вернётся к идее.
Custdev или «кастдев». Опрос потенциальных клиентов о том, насколько продукт решает их проблему. При чём кастдев можно проводить, когда продукт только в планах или уже на стадии разработки. Здесь важно понять, какие боли у целевой аудитории, что они уже делают, чтобы их закрыть и чего для этого не хватает. Кастдев показывает разработчику, что именно нужно пользователю и на каких фичах надо сфокусироваться.
У нас может быть куча классных идей, но некоторые будут неприменимы для пользователей. Это как в меме про кошку. Хозяева купили ей крутой многоуровневый дом с игрушками и когтеточками, а она выбрала картонную коробку от него. Так вот, прежде, чем покупать кошке замок, спросите, что ей на самом деле нужно.
👉 Предлагайте команде провести кастдев перед каждым проектом. Без него вы работаете на удачу, даже если верите, что придумали лучший продукт в мире. Возможно, так оно и есть, но стоит заранее это проверить.
A/B Testing или «A/B тестирование». Так называют проверку гипотез на пользователях. Цель — выяснить, какая из них работает лучше. Например, дизайнер разработал три варианта для кнопки сайта, а маркетологу нужно определить самый кликабельный. Через какой-нибудь VWO он настраивает A/B-тест:
- Треть посетителей видит первую версию кнопки
- Ещё одна треть — вторую.
- Остальные — третью.
- Когда наберется достаточная выборка, маркетолог анализирует конверсию каждой кнопки и принимает решение.
Тестирование можно провести вручную. Для этого соберите большую выборку людей и разделите на три равные группы. Покажите варианты так, чтобы одна группа видела только один дизайн. Подготовьте вопросы и критерии оценки, проведите с ними тестирование и сделайте выводы.
👉 Если маркетолог говорит «нужен A/B тест» — не отмахивайтесь. Он хочет не растранжирить бюджет, а проверить, какая гипотеза реально работает. Так вы даже сэкономите, потому что выберете правильный путь развития продукта.
Планирование и управление
Scope или «скоуп». Это границы проекта и объём работ. Скоуп определяет цели и ограничения проекта, а главное: что входит в него, а что нет. Без скоупа заказчик может регулярно добавлять задачи или просить переделать. Скоуп помогает исполнителю и заказчику синхронизироваться и двигаться в одном направлении.
👉 Если чувствуете, что заказчик просит больше, чем договаривались, скажите: «Этого нет в скоупе». Звучит мягче, чем «этого нет в ТЗ», не тянет в юридическую плоскость и не создаёт конфликт. То, чего нет в скоупе, — дополнительная задача, а значит и дополнительные ресурсы.
Приведу пример из практики. Мы взялись за сложную разработку, утвердили скоуп. Через некоторое время заказчик предложил добавить интеграцию с телефонией. Мы сказали: стоп, этого не было в скоупе. Предложили положить задачу в бэклог и вернуться к ней после MVP — готовой тестовой версии продукта. Потом мы назначили встречу и решили, что интеграция с телефонией действительно нужна. Сделали её за отдельную плату.
Status Report или «статус репорт». Документ, который показывает итоги прогресса по проекту. Этот регулярный срез нужен, чтобы понять, что сделано, что в работе, что застряло и что делать дальше. Если игнорировать статус репорт, можно не заметить проблемы и заминки вовремя.
Например, в агентстве отдали задачу проверенному специалисту. Месяц его не трогали и не просили репорт — человек же надёжный. За два дня до дедлайна спрашивают, готова ли задача. Оказывается, что-то пошло не так ещё на второй неделе, но он не предупредил: думал разрулит к сроку. Аванс вернул, но работа не сделана, а заказчик ждёт результат послезавтра. Своевременный статус репорт обнаружил бы проблему вовремя — агентство успело бы поменять исполнителя и предупредить заказчика о новых сроках.
Статус-репорт — это не контроль ради контроля, а способ вовремя увидеть риск, пока ещё можно что-то сделать. Как часто его проводить каждый решает сам. Но не делать вообще — дорого обходится.
👉 Определите, как часто будете делать статус репорт и регулярно сверяйтесь с командой. Если сомневаетесь, что с проектом всё окей, то попросите внеплановый репорт. Это работает и внутри команды, и с заказчиком.
Bench или «бэнч». С английского — «скамейка запасных игроков». В первую очередь термин применяют и к внештатникам, с которыми есть договорённости взяться в любой момент за работу. Или даже к тёплым контактам исполнителей, к которым можно срочно обратиться с заказом. А ещё так называют резервных сотрудников, которые получают зарплату и социальные гарантии, но временно не заняты в проектах.
Для агентства или IT-компании бэнч — это не роскошь, а необходимость. Поздно будет бежать и собирать людей с нуля, если уйдёт ключевой разработчик или появится сразу несколько новых клиентов. Бэнч — это буфер, который позволяет быстро реагировать. Как кадровый резерв, только в реальном времени.
👉 Попросите эйчаров подготовить бэнч. Заранее продумайте, как вы можете поддерживать интерес резервных сотрудников.
