Привет! Сегодня я хочу поговорить с вами о самом начале любого IT-проекта. ⏳ О моменте, когда всё только зарождается и когда совершается больше всего фатальных ошибок. Речь пойдет о сборе требований.
Почему эта тема? Да потому что фраза «клиент сам не знает, чего хочет» уже стала мемом. 🤷♂️ Но наша задача — не посмеяться над заказчиком, а помочь ему сформулировать свои хотелки так, чтобы программисты написали именно то, что нужно, а не «чтобы работало, но я не знаю как».
Давайте разберем 5 шагов, которые превращают хаос в техническое задание. 👇
Шаг 1. 🛒 Готовь сани летом, а вопросы — до встречи
Самая большая ошибка новичка — приходить на встречу с заказчиком «с чистой головой». Так делать нельзя. Это как идти в супермаркет без списка покупок: куча денег потрачена, а дома все равно есть нечего.
Что нужно сделать до интервью:
- Изучить контекст. 🔍 Если мы автоматизируем отдел продаж — почитайте, чем этот отдел вообще занимается. Если делаете сайт для пиццерии — закажите там пиццу, посмотрите на конкурентов.
- Набросать список вопросов. 📝 Они будут меняться по ходу встречи, но у вас должна быть «шпаргалка», чтобы ничего не забыть. Вопросы делятся на:
Бизнес-вопросы: 💰 Зачем вам это? Какая главная цель? Сколько денег/времени это должно экономить?
Функциональные вопросы: ⚙️ Что должна делать система? Кто будет ей пользоваться?
Технические вопросы: 🖥️ (Если вы с ними столкнулись раньше времени).
Шаг 2. 🎩 Магия интервью: слушаем и записываем
Вы пришли на встречу. Заказчик полон энергии и начинает рассказывать: «Мне нужно, чтобы тут была кнопка, как вон в том приложении, ну знаешь, такая зеленая и все само считало, и еще чтобы отчеты красивые были, а еще у конкурентов есть фишка с уведомлениями...».
Ваш мозг кипит. 🤯 Как это структурировать?
Золотые правила интервью:
- Уточняйте общие слова. 🧐 Заказчик говорит «удобно», «красиво», «быстро». Для него «быстро» — это 5 секунд, для программиста — 2 дня загрузки. Уточняйте: «Расскажите подробнее, что значит "удобно" для вас?», «Сколько секунд система должна обрабатывать запрос, чтобы вы были довольны?».
- Просите примеры. 💡 Вместо «много клиентов» — «сколько именно? 100 или 10 000?». Это сразу повлияет на архитектуру базы данных.
- Рисуйте на доске. 📊 Блок-схемы — язык, понятный всем. «Вы нажимаете здесь, система проверяет данные вот тут, потом отправляет запрос Петровичу... Заказчик, я правильно понял логику?»
Шаг 3. 🛠️ Инструментарий разведчика: используем все органы чувств
Интервью — это хорошо, но люди часто забывают детали или не считают нужным о них говорить. Поэтому используем дополнительные методы.
- Анкетирование. 📋 Если пользователей много (например, 100 человек в разных городах), опросите их через Google Forms. Это поможет собрать статистику.
- Анализ документов. 📂 Попросите показать текущие инструкции, бланки, отчеты, которые они заполняют сейчас (даже в Excel). Вы увидите реальные поля: «ФИО», «Адрес», «Сумма заказа». Это уже готовые поля для вашей будущей базы данных.
- Наблюдение. 👀 Самый крутой метод. Придите и посидите час рядом с сотрудником. Посмотрите, как именно он работает. Вы увидите те «костыли» и лайфхаки, о которых он сам не расскажет: «Я ввожу данные в программу, потом переписываю их в блокнот, чтобы вечером не забыть позвонить клиенту». Бинго! Вот оно — скрытое требование! 🎯
Шаг 4. 🖼️ Прототип: лучше один раз увидеть
Самый лучший способ проверить, правильно ли вы поняли заказчика — показать ему картинку. Не код, не сложную схему, а просто картинку будущего экрана (это называется прототип или wireframe).
Нарисовать можно даже на бумаге ✍️ или в специальных программах вроде Figma.
- «Смотрите, вот тут у вас будет поле ввода номера телефона».
- «Вот тут — кнопка "Отправить отчет"».
- «После нажатия появляется вот такое окошко с предупреждением».
Заказчик либо скажет: «Да, идеально!» 👍, либо: «Ой, нет, мне нужно, чтобы еще и чек тут же печатался!». На этом этапе исправить ошибку стоит копейку. На этапе готового продукта — миллион и испорченные нервы. 💔
Шаг 5. 🔒 Фиксируем договоренности. Железно.
Встреча прошла отлично, все кивали, жали руки. Не обольщайтесь! Через 3 дня заказчик может вспомнить, что хотел «еще вот эту зеленую кнопку». 🟢
Ваше главное оружие — документ (Техническое задание или Спецификация).
После встречи вы обязаны выслать письмо/файл: «Иван Иванович, спасибо за встречу! Мы договорились о следующем:
- Система должна считать налоги автоматически.
- Пользователей будет 3 типа: администратор, бухгалтер, кладовщик.
- Отчет должен формироваться не дольше 10 секунд.
Жду вашего подтверждения, чтобы двигаться дальше!»
Если заказчик отвечает «Да, все верно» ✅, вы защищены. Если он потом придет и скажет «А где же кнопка?», вы покажете письмо: «Мы это не обсуждали, давайте сделаем отдельной задачей». Это экономит бюджет и время. ⏱️
Вместо заключения: 🤫 Главный секрет сбора требований
Сбор требований — это не допрос. Это совместное творчество. 🤝 Вы не просто переписываете желания заказчика, вы помогаете ему увидеть его бизнес со стороны, находите узкие места и предлагаете, как их улучшить с помощью IT.
Плохой аналитик: «Что сделать?».
Хороший аналитик: «Какую проблему решаем? А что будет, если мы сделаем вот так? А не проще ли вообще убрать этот шаг?».
Становитесь детективом 🕵️♂️ и немного психологом 🧠, и тогда ваши проекты будут нравиться и заказчикам, и программистам. ❤️
А как вы собираете требования? Были ли у вас забавные случаи, когда заказчик просил одно, а в итоге оказывалось нужно совсем другое? Делитесь в комментариях! 💬
Подписывайся https://t.me/analist_analist_analist