Pull to refresh

Почему мы никогда не составляем ТЗ. А что взамен?

Reading time 3 min
Views 4.5K
Есть разные методологии разработки. Каждый выбирает себе тот подход, который максимально эффективно подходит компании-разработчику. В качестве основы для собственной методологии мы используем экстремальное программирование (XP). Конечно же мы внесли в нее собственные изменения, но сегодня я бы хотел рассказать не об этом.



Любой проект начинается с технического задания. Так было раньше, а для многих это остается аксиомой до сих пор. Это не плохо, однако мы практически полностью отказались от ТЗ. Теперь это сокращает нам огромное количество времени, которое тратилось раннее практически впустую.

Пользователь должен составить ТЗ


Самый неэффективный способ построения ТЗ — общаться с пользователями. Но как же так, возразите вы, ведь программы пишутся для пользователей! Да, программы пишутся для пользователей, но не пользователями. Представьте себе некого работника, который день в день закручивает гайки на конвейере. Вы спросите его, что нужно сделать, чтобы ему было удобно закручивать гайки? Он скажет, что желательно сделать автоподстраивающийся ключ, который не нужно выставлять в нужное положение, чтобы попасть им на гайку. Нужен ключ, который сам крутит гайки, нужен удобный стул, чтобы не стоять возле конвейера и так далее. Вы скрупулезно запишите все пожелания и внесете их в ТЗ. Ведь вы решаете реальные проблемы пользователя! Идете ко второму работнику, а он рассказывает вам, что неплохо бы было сделать кран с водой и холодильник с бутербродами недалеко от рабочего места, чтобы можно было перекусывать во время работы. Третего все и так устраивает, ну что только музончик нужен, нудная работа ведь.

Итак, мы записали все пожелания работников. Теперь вопрос, а какова эффективность решения насущных проблем пользователей с точки зрения компании? Думаю, что она колеблется около нуля. Это все равно, что перекрасить все кнопочки в синий цвет. Вроде и что-то сделали, но толку от этого…

К кому нужно идти за ТЗ?


К тому, кто строит процессы. Это могут быть начальники отделов и начальники начальников, отделы планирования и так далее.

Работник знает только свой процесс, да и тот навязан ему свыше. Начальник же знает процессы всех работников в подчинении и процессы взаимодействия с другими отделами. Именно это и важно. Для начала стоит попробовать не пытаться подстаивать бизнес-процессы под возможности программы, а реализовывать их в коде. Тогда программа будет иметь смысл и ее будут использовать. В противном случае все отправят в ящик стола уже через месяц, а может и раньше. Как мне кажется, Google Wave не был принят пользователями только потому, что не решал проблемы, а акцентировал внимание на процессе. Процесс как вещь в себе, в отрыве от реальности, слабоинтересен.

Опять же, не пытайтесь выжать из этих людей максимум. Станьте на место простого начальника отдела. Помимо поддерживания хрупкого порядка в хаосе флуктуаций потоков сознания, поступков и решений подчиненных, ему нужно еще и заниматься составлением документа, который для него является не то чтобы третьестепенным, он вообще далеко за горизонтом дел на исполнение. Да и вопросы, которые вы будете им задавать для них равносильны вопросам по типу: «Расскажите подробно о процессе ковыряния в носу». Поговорить можно, но денег эти разговоры в данный момент времени не приносят.

Что делать, если бизнес-процесс не формализован?


Тогда придется вам создать его самостоятельно. Да, именно разработчику нужно предлагать бизнес-процесс заказчику. Для этого придется потратить время на изучение методологий работы клиента, вникнуть в его проблемы, определить ключевые моменты автоматизации. Предложения должны поступать на всем этапе разработки, а не только на момент формализации неких общих требований. Каждый разработчик без исключения должнен знать, зачем он что-либо делает, какова причина, какой бизнес-процесс воплощается в коде.

Самый идеальный заказчик, по моему мнению, это тот, который доверяет тебе не просто автоматизацию собственных процессов, но и их реорганизацию для достижения наибольшего эффекта от автоматизации. Звучит пародоксально, но наиболее успешные примеры автоматизации получаются там, где ТЗ минимально. Это как та заветная кнопка «Сделать красиво».

Красноречивый прототип


Ничто не стимулирует формализацию требований со стороны заказчика лучше, чем прототип. Он наглядно демонстрирует ему все прелести и недостатки внутренней организации процесса производства. О прототипах и без меня достаточно написано, так что не буду на этом останавливаться.

Но как без ТЗ?


Мы заменили ТЗ некими картами проблем. Это краткое изложение задач для решения, написанное вольным стилем. Решили проблему = выполнили договоренности. Все просто.

На время разработки мы словно становимся отделом компании заказчика, который параллельно работает на единый результат. Совместная работа над задачами подстегивает заказчика думать над упорядочиванием мыслей касательно формализации краткого ТЗ, но вместе с этим не сильно мешает выполнять ежедневную работу по ведению бизнеса. Получается такая себе ненавязчивая разработка.

Подводя итоги


Конечно же это не серебряная пуля и не панацея от всех бед. Каждый должен выбирать свой путь в развитии бизнеса и искать лучшие решения для сложившейся коньюктуры рынка.

Удачи вам в вашем бизнесе!
Tags:
Hubs:
+25
Comments 110
Comments Comments 110

Articles