The post has been translated automatically. Original language: Russian
A large company sends forty pages of technical specifications. Half of the requirements argue with the other half, the deadlines are taken from the ceiling, and at the first meeting it turns out that a third of the functions "need to be discussed separately." Previously, in such a situation, we signed a contract and sat down to develop it. After several painful projects, they realized that this was not the way to do it.
Why raw TK is dangerous
TK from a large company almost never reflects reality. The document is usually backed by a legacy system, coordination between departments, and the author of the TOR, who has already resigned. You fix the estimate for such a document blindly, and then either you go into negative territory, or you start saving, and the customer feels it. Both scenarios are bad.
Audit as a separate first stage
We began to take the analysis to a separate paid stage before development. What does it include:
- analysis of the current architecture and infrastructure;
- separation of real needs from what got into TK by inertia;
- talk to those who will use the system, not just those who sign the bills;
- search for risks that are not mentioned in the TOR.
At the exit, the customer receives a consistent technical specification, architecture, assessment stages, and a risk map. These artifacts are valuable in themselves: even if a person leaves to make a product with another team, he takes away a working document, not scraps.
Separately, about "paid". At first, it was awkward to take money for analysis, until we noticed a pattern: free work is treated as free. Money dramatically increases both the customer's engagement and the seriousness of the conversation.
How does this turn into development
After the audit, we are not discussing an abstract TOR, but a specific plan that we have drawn up ourselves and which the customer has already seen. Next, we go in iterations of two weeks with a demo, so that the edits pop up early, and not at the final acceptance. The structure is ready in advance, so we carry out tasks in parallel, and we consult with colleagues from other companies on controversial forks: a fresh look has more than once saved us from a solution that looked logical from the inside, but turned out to be a dead end.
What we learned along the way
The audit cannot be stretched out: it will turn into a month of correspondence, and the meaning of a quick first step is lost.
Sometimes the honest conclusion of an audit is "you don't need development." You lose a project in the short term, you gain trust in the long term, and such customers come back.
The scheme does not work everywhere. For a large system with a high cost of error, auditing pays off, but it is redundant for landing pages.
And most importantly: a paid audit is a filter in itself. Those who are not ready to invest in the analysis of their system will almost certainly not reach the end of a large project.
Question to the community
How do you enter major projects? Do you take the technical specifications as they are, or do you analyze them first? And if the analysis is paid or at your own expense? It is interesting to compare approaches.
Крупная компания присылает ТЗ на сорок страниц. Половина требований спорит с другой половиной, сроки взяты с потолка, а на первой встрече выясняется, что треть функций «надо обсудить отдельно». Раньше мы в такой ситуации подписывали договор и садились за разработку. Несколько болезненных проектов спустя поняли, что так нельзя.
Почему сырое ТЗ опасно
ТЗ от крупной компании почти никогда не отражает реальность. За документом обычно стоит legacy-система, согласования между отделами и автор ТЗ, который уже уволился. Зафиксируешь смету по такому документу вслепую, и дальше либо уходишь в минус, либо начинаешь экономить, а заказчик это чувствует. Оба сценария плохие.
Аудит как отдельный первый этап
Мы стали выносить разбор в отдельный платный этап до разработки. Что в него входит:
- разбор текущей архитектуры и инфраструктуры;
- отделение реальных потребностей от того, что попало в ТЗ по инерции;
- разговор с теми, кто будет пользоваться системой, а не только с теми, кто подписывает счета;
- поиск рисков, которые в ТЗ не упомянуты.
На выходе заказчик получает непротиворечивое ТЗ, архитектуру, этапы с оценкой и карту рисков. Эти артефакты самоценны: даже если человек уйдёт делать продукт с другой командой, он уносит рабочий документ, а не обрывки.
Отдельно про «платный». Первое время было неловко брать деньги за анализ, пока не заметили закономерность: к бесплатной работе относятся как к бесплатной. Деньги резко поднимают и вовлечённость заказчика, и серьёзность разговора.
Как это превращается в разработку
После аудита обсуждаем не абстрактное ТЗ, а конкретный план, который сами составили и который заказчик уже видел. Дальше идём итерациями по две недели с демо, чтобы правки всплывали рано, а не на финальной приёмке. Структура готова заранее, поэтому задачи ведём параллельно, а по спорным развилкам советуемся с коллегами из других компаний: свежий взгляд не раз спасал от решения, которое изнутри выглядело логичным, а оказывалось тупиковым.
Что мы поняли по дороге
Аудит нельзя растягивать: превратится в месяц переписки, и теряется смысл быстрого первого шага.
Иногда честный вывод аудита это «вам не нужна разработка». Краткосрочно теряешь проект, в долгую получаешь доверие, и такие заказчики возвращались.
Схема работает не везде. Для большой системы с высокой ценой ошибки аудит окупается, для лендинга он избыточен.
И главное: платный аудит сам по себе фильтр. Кто не готов вложиться в разбор своей системы, почти наверняка не дойдёт и до конца большого проекта.
Вопрос к сообществу
А у вас вход в крупные проекты как устроен: берёте ТЗ как есть или сначала делаете свой разбор? И если разбор, то платный или за свой счёт? Любопытно сравнить подходы.
