Добавить в корзинуПозвонить
Найти в Дзене
Максим Зубеев

215

Я не люблю работать по ТЗ Поймал себя на мысли, что одна из самых крамольных фраз для интегратора звучит именно так... И нет, это не потому, что я люблю хаос, импровизацию и шаманство на проде. Ровно наоборот. Просто ТЗ очень часто — это не описание проблемы. Это описание чужой версии решения. А вот это уже опасная штука. Недавно наткнулся на хорошую мысль Дженсена Хуанга (CEO NVidia) Цель инженера — решать известные проблемы и находить новые. Код — это одна из задач. Но если твоя цель буквально кодить — тебе скидывают задачу, ты кодишь — ну окей, возможно тебя заменит AI. Но у большинства наших инженеров цель — решать проблемы. И знаете что — у нас в компании столько проблем, и столько ещё ненайденных проблем, что чем больше у них времени копать вглубь, тем лучше для компании. Ничто не принесло бы мне больше кайфа, чем если бы никто из них вообще не писал код — а просто решал проблемы, понимаете? Вот этот фреймворк "цель vs задача" — его реально полезно примерить на себя каждому.

215. Я не люблю работать по ТЗ

Поймал себя на мысли, что одна из самых крамольных фраз для интегратора звучит именно так...

И нет, это не потому, что я люблю хаос, импровизацию и шаманство на проде.

Ровно наоборот.

Просто ТЗ очень часто — это не описание проблемы.

Это описание чужой версии решения.

А вот это уже опасная штука.

Недавно наткнулся на хорошую мысль Дженсена Хуанга (CEO NVidia)

Цель инженера — решать известные проблемы и находить новые. Код — это одна из задач. Но если твоя цель буквально кодить — тебе скидывают задачу, ты кодишь — ну окей, возможно тебя заменит AI. Но у большинства наших инженеров цель — решать проблемы. И знаете что — у нас в компании столько проблем, и столько ещё ненайденных проблем, что чем больше у них времени копать вглубь, тем лучше для компании. Ничто не принесло бы мне больше кайфа, чем если бы никто из них вообще не писал код — а просто решал проблемы, понимаете? Вот этот фреймворк "цель vs задача" — его реально полезно примерить на себя каждому.

Вот здесь у меня прям полное совпадение.

⚡️ Я не люблю работать по ТЗ, когда ТЗ подменяет мышление.

Когда мне приносят не бизнес-проблему, а уже готовую конструкцию в духе:

«подключите телеграм к Битрикс24 и настройте автоматическую постановку задач».

Такое ТЗ можно взять и честно реализовать.

Аккуратно. Красиво. По пунктам.

С бантиком. С актом. С ощущением выполненного долга.

А потом внезапно выясняется, что проблема вообще была не в телеге.

Проблема была в том, что РОП терял заявки из мессенджеров.

Менеджеры тонули в дублях.

Роли пересекались.

Этапы никто нормально не контролировал.

А воронка жила своей отдельной жизнью, как кот, который уже не ваш.

❗️ То есть задача была:

"настроить чат".

⚡️ А реальная проблема была "система не управляет продажами"

Именно поэтому я не люблю работать по ТЗ в лоб.

Потому что ТЗ очень часто лечит симптомы... А мне интересны причины.

⬅️ Добавьте поле в сделку

может означать

➡️ мы теряем данные и уже не понимаем, откуда идут деньги

⬅️ Сделайте согласование

может означать

➡️ у нас ручной бардак и решения висят неделями

⬅️ Настройте воронку

может означать

➡️ у нас в принципе никто не понимает, как устроены продажи

Если интегратор просто берёт ТЗ и молча его исполняет, он становится человеком-кнопкой.

А у человека-кнопки, скажем так, сейчас плохие рыночные перспективы.

🤎 Мне гораздо ближе другой подход.

Сначала понять, что у бизнеса болит на самом деле;

— где теряются деньги;

— где теряется время;

— где процесс не помогает, а мешает;

и только потом решать, нужен там телеграм, AI, бизнес-процесс, новое поле или половину этого добра вообще лучше не внедрять, а выкинуть.

🤎 Хорошее ТЗ я люблю.

Но как финал мышления, а не его замену.

— Сначала диагноз.

— Потом решение.

— Потом уже ТЗ.

А не наоборот.

#систематизируйэто

@Максим Зубеев