«У меня есть программист, и он сам обещал придумать, как сделать сайт»
Программист может спроектировать систему. У него для этого есть и знания, и опыт. Но есть две объективные причины, почему это почти всегда заканчивается плохо — и они не имеют отношения к его квалификации.
Причина №1. Он не может оттестировать то, что сам написал
Это не про «плохого программиста». Это про человеческую психологию.
Когда вы пишете код, вы мысленно держите в голове всю логику. Вы знаете, как система должна работать. Вы знаете, какие данные куда передаются. Вы знаете, какие кнопки что делают.
И именно это знание мешает вам найти ошибки.
| Кто тестирует | Как работает |
|---|---|
| Программист | Он тестирует систему «как задумано». Он проверяет сценарии, которые сам же и спроектировал. Он не думает: «а что будет, если пользователь нажмёт не туда, введёт не то, или отправит форму дважды». Он считает, что пользователь «будет делать правильно». |
| Хороший тестировщик | Он не знает, «как задумано». И это его суперсила. Он нажимает на кнопки в случайном порядке, вводит в поля «1234567890», отправляет пустые формы, открывает страницу в 20 вкладках одновременно. Он делает идиотизм — не потому что он глупый, а потому что он не зашорен знанием «так не задумано». |
Хороший тестировщик находит ошибки, которые программист никогда не найдёт. Потому что программист знает, где система должна работать, а тестировщик проверяет, где она может сломаться.
Причина №2. У программиста нет времени на глубокий анализ и детальное описание
Это не про «лень». Это про реальность работы.
Программист — это человек, который пишет код. И у него есть текущие задачи:
- — Доработать модуль X.
- — Исправить баг в интеграции.
- — Сдать релиз к пятнице.
- — Обновить библиотеки.
Где в этом графике время на то, чтобы:
- — Сесть и спроектировать архитектуру?
- — Нарисовать схемы БД и согласовать их с аналитиками?
- — Написать детальное ТЗ, которое можно отдать джуниору?
- — Продумать все сценарии и исключения?
- — Документировать API?
- — Описать, как система будет масштабироваться через год?
Его нет. И если программист говорит «я сам всё спроектирую» — он не вредит специально. Он просто не осознаёт, сколько времени на самом деле занимает хорошее проектирование.
Что на самом деле происходит, когда программист «сам придумывает»
| Этап | Что происходит |
|---|---|
| Начало | Программист пишет код. Быстро. «Сделаем как есть, потом переделаем». |
| Середина | Появляются первые сложности. «А как это должно работать с 1С?» — «Ну, сделаем как получится». |
| Конец | Система работает. Как-то. Но тестировать её нечем. И документации нет. |
| Через 3 месяца | Приходит новый разработчик. Он не понимает, что тут написано. «А где ТЗ?» — «Его нет». |
| Через 6 месяцев | Клиенты начинают жаловаться на баги. Интеграции падают. Никто не знает, как это чинить. |
Итог: вы сэкономили на ТЗ и архитектуре. Но потратили в 3 раза больше на переделки, поддержку и потерю репутации.
Вопросы, которые НЕЛЬЗЯ задавать программисту
Программист — эксперт по коду. Он не эксперт в вашем бизнесе. Если вы начнёте задавать ему эти вопросы, он будет угадывать. А угадывать — это путь к хаосу.
| Вопрос | Почему нельзя задавать |
|---|---|
| «Как должна быть устроена база данных?» | Он не знает, какие отчёты вы будете строить через год. Если спроектирует неправильно — через год вы не сможете сделать отчёт «по продажам в разрезе менеджеров». |
| «Какие интеграции с 1С нам нужны?» | Он не знает, как устроен ваш документооборот. Сделает формальный обмен, а через месяц окажется, что не хватает поля «комментарий менеджера». |
| «Как должны выглядеть экраны?» | Он не знает, как работает ваш клиент. Он сделает «красиво», а клиент не поймёт, куда нажимать. |
| «Какие роли нужно сделать в личном кабинете?» | Он не знает, кто ваши пользователи. Сделает «админа» и «юзера», а через месяц окажется, что нужен ещё и «менеджер по работе с клиентами» с особыми правами. |
| «Какая архитектура подойдёт для нашего проекта?» | Он не знает, сколько у вас будет пользователей через год. Сделает на одном сервере, а через год всё ляжет под нагрузкой. |
Что делать вместо этого
- 1. Разделите роли. Программист — пишет код. Архитектор или техписатель — проектирует систему. Да, это два человека. Но это не «допрасход». Это инвестиция в ясность.
- 2. Дайте программисту ТЗ. Чтобы он не гадал, а просто брал и делал. Это экономит его время и ваши нервы.
- 3. Наймите тестировщика. Хотя бы на время финальной проверки. Он найдёт то, что программист не заметил.
- 4. Не принимайте решение «на глаз». Если программист говорит «я сам придумаю» — спросите его: «А кто будет это тестировать? А кто напишет документацию? А что будет, если ты уйдёшь?»
Итог
Программист может спроектировать систему. Но для этого нужны:
- — Время — которого у него нет, потому что он пишет код.
- — Вводные — которых у него нет, потому что он не знает ваш бизнес.
- — Человек, который оттестирует — потому что он сам не может объективно проверить свою работу.
Не заставляйте программиста быть архитектором, тестировщиком и техписателем одновременно. Он будет делать всё плохо. Не потому, что он плохой специалист. А потому, что это невозможно делать хорошо в одном лице.
Потратьте деньги на проектирование и тестирование сейчас — и сэкономите в 2–3 раза больше на переделках через полгода.
Если ваш программист говорит «я сам придумаю» — это не повод увольнять его. Это повод дать ему чёткое ТЗ и нанять тестировщика.
Напишите мне. Я помогу вам определить, что нужно спроектировать, и составлю чёткое ТЗ, по которому ваш программист будет работать без переспросов.