Недавно я наткнулся на одну мелкую и ядовитую историю, которая сподвигла меня встать на фоне заката, запустить руку в бороду и рассказать вам про CJM - Customer Journey Map. Если вы знаете про CJM, мотайте ленту вниз - в следующем посте я как раз исхожу злобой по поводу этой истории, - а тут я хочу разъяснить азы советской власти.
CJM, вообще говоря, предназначен для решения следующей проблемы: у нас есть пользователь со своими задачами и болью, у нас есть разрабатываемый продукт со всеми функциональными пирогами, так как же они будут взазимодействовать между собой, спрашивается? Как же нам избежать известной жопы, когда вроде и продукт ок, и пользователь ок, а между собой они не дружат? Как заставить агнца возлечь возле льва?
Про CJM принято думать, что это что-то АДСКИ СЛОЖНОЕ и вообще МАТАН, в доказательство чего все тыкают в статьи разных экспертов с дубовыми схемами, формулами и грандиозными диаграммами.
А я вам говорю, что никакого матана в CJM нет. Щас расскажу. Берем и делаем вот что:
1. Садимся, берем реального и гипотетического пользователя, понимаем, какую задачу он хочет решить (или какой цели достичь), в каком контексте и с какими дополнительными обстоятельствами. Этот пункт удобно проворачивать при помощи метода персонажей, но я про него в другой раз расскажу.
2. Расписываем квадратиками в ряд: для достижения своей цели пользователь делает вот это, потом вот это, потом вон то - а потом вон то.
3. Смотрим внимательно на квадратики и думаем: а чем наш продукт сможет помочь пользователю на каждом шаге? И пишем чуть ниже напротив каждого квадратика: вот здесь продукт будет делать все за пользователя, вот тут пользователю будет предложен выбор, здесь ему будет приходить пуш-уведомление - и так далее.
4. Любуемся теперь уже двумя наборами квадратиков, идущих рядом - и вслед за этим начинаем думать: а какие терки могут возникать между пользователем и продуктом на каждом шаге? Например, вот здесь пользователь должен будет выбрать из 20 очень похожих вариантов; это нехорошо. Здесь пользователь должен будет не пропустить пуш-уведомление, иначе он ничего не сможет сделать дальше; это тоже не очень гут. Аккуратно расписываем все эти терки напротив каждого квадрата.
И… всё. Не, серьезно, всё. У вас уже готов минималистичный CJM, который позволяет понять, как действует пользователь, как ему помогает продукт - и какие помехи и проблемы возникают в процессе.
Конечно, есть еще тонна нюансов, но их можно постигать в процессе. Например, CJM нужно составлять не только для того отрезка времени, пока пользователь контактирует с продуктом, а смотреть еще, что пользователь делал до и после. При составлении CJM важно по максимуму использовать реальные данные, а если фантазировать - то отмечать это как свою собственную гипотезу.
Еще - по ситуации - можно расписывать CJM более глубоко и подробно, например:
- Для каждого шага описывать мысли и эмоции пользователя;
- Для каждого шага описывать, с какими интерфейсными блоками, страницами или экранами пользователь будет взаимодействовать
- Расписывать, какие интеграции с внешними системами нам понадобятся для осуществления каждого шага;
- Указывать взаимосвязь с бизнес-процессами, завязанными на пользовательский сценарий (например, пользователь покупает товар - а вот тут мы активируем бизнес-процесс заказа внутри организации);
- Раскидывать CJM на несколько каналов (соцсети, приложение и т.п.) и смотреть, как пользователь переходит из одного места в другое;
- На основе CJM рисовать конверсионную воронку - то есть указывать для каждого этапа метрики и KPI, которыми мы будем мерять эффективность прохождения пользователем сценария.
Ну и ооочень много чего еще, что вы обычно видите в статьях и материалах от CJM-гуру. CJM - охрененно гибкий формат, на который вы можете накрутить все, что хотите, но начать можете с совсем малого и простого, и уже будет очень много пользы.
Так что не бойтесь и пробуйте.
#вашидокументы
CJM, вообще говоря, предназначен для решения следующей проблемы: у нас есть пользователь со своими задачами и болью, у нас есть разрабатываемый продукт со всеми функциональными пирогами, так как же они будут взазимодействовать между собой, спрашивается? Как же нам избежать известной жопы, когда вроде и продукт ок, и пользователь ок, а между собой они не дружат? Как заставить агнца возлечь возле льва?
Про CJM принято думать, что это что-то АДСКИ СЛОЖНОЕ и вообще МАТАН, в доказательство чего все тыкают в статьи разных экспертов с дубовыми схемами, формулами и грандиозными диаграммами.
А я вам говорю, что никакого матана в CJM нет. Щас расскажу. Берем и делаем вот что:
1. Садимся, берем реального и гипотетического пользователя, понимаем, какую задачу он хочет решить (или какой цели достичь), в каком контексте и с какими дополнительными обстоятельствами. Этот пункт удобно проворачивать при помощи метода персонажей, но я про него в другой раз расскажу.
2. Расписываем квадратиками в ряд: для достижения своей цели пользователь делает вот это, потом вот это, потом вон то - а потом вон то.
3. Смотрим внимательно на квадратики и думаем: а чем наш продукт сможет помочь пользователю на каждом шаге? И пишем чуть ниже напротив каждого квадратика: вот здесь продукт будет делать все за пользователя, вот тут пользователю будет предложен выбор, здесь ему будет приходить пуш-уведомление - и так далее.
4. Любуемся теперь уже двумя наборами квадратиков, идущих рядом - и вслед за этим начинаем думать: а какие терки могут возникать между пользователем и продуктом на каждом шаге? Например, вот здесь пользователь должен будет выбрать из 20 очень похожих вариантов; это нехорошо. Здесь пользователь должен будет не пропустить пуш-уведомление, иначе он ничего не сможет сделать дальше; это тоже не очень гут. Аккуратно расписываем все эти терки напротив каждого квадрата.
И… всё. Не, серьезно, всё. У вас уже готов минималистичный CJM, который позволяет понять, как действует пользователь, как ему помогает продукт - и какие помехи и проблемы возникают в процессе.
Конечно, есть еще тонна нюансов, но их можно постигать в процессе. Например, CJM нужно составлять не только для того отрезка времени, пока пользователь контактирует с продуктом, а смотреть еще, что пользователь делал до и после. При составлении CJM важно по максимуму использовать реальные данные, а если фантазировать - то отмечать это как свою собственную гипотезу.
Еще - по ситуации - можно расписывать CJM более глубоко и подробно, например:
- Для каждого шага описывать мысли и эмоции пользователя;
- Для каждого шага описывать, с какими интерфейсными блоками, страницами или экранами пользователь будет взаимодействовать
- Расписывать, какие интеграции с внешними системами нам понадобятся для осуществления каждого шага;
- Указывать взаимосвязь с бизнес-процессами, завязанными на пользовательский сценарий (например, пользователь покупает товар - а вот тут мы активируем бизнес-процесс заказа внутри организации);
- Раскидывать CJM на несколько каналов (соцсети, приложение и т.п.) и смотреть, как пользователь переходит из одного места в другое;
- На основе CJM рисовать конверсионную воронку - то есть указывать для каждого этапа метрики и KPI, которыми мы будем мерять эффективность прохождения пользователем сценария.
Ну и ооочень много чего еще, что вы обычно видите в статьях и материалах от CJM-гуру. CJM - охрененно гибкий формат, на который вы можете накрутить все, что хотите, но начать можете с совсем малого и простого, и уже будет очень много пользы.
Так что не бойтесь и пробуйте.
#вашидокументы
Так вот, про ТЗ. Как вы заметили по голосованию выше, под ТЗ все подразумевают совершенно разное, и дискуссия «что такое ТЗ» неизбежно вырождается в спор глухого с тупым - очень сложно сойтись в своих оценках, когда ты даже под одними и теми же словами понимаешь разное.
Поэтому во исполнение Федеральной программы по соблюдению здравого смысла (которую я выдумал только что) я хочу призвать вас отвлечься от ТЗ и задуматься - а какую роль вообще выполняют всякие описательные документы в процессе разработки?
Этих ролей не так уж и много - всего четыре штуки.
Роль первая - выражение идеи. Когда вы придумываете продукт (будь вы заказчик или разработчик), то вы рано или поздно должны сформулировать его общую идею и донести ее до окружающих - заказчика, подрядчика, команды, начальства, самого себя, в конце концов. Хорошо, если идея будет сопровождаться еще и описанием решаемой задачи - это облегчает понимание того, нахрена вы все тут собрались. Это полезно делать как с чисто коммуникационной точки зрения, чтобы все были в курсе, так и с точки зрения планирования - сложно составлять какие-либо дорожные карты, когда ваш продукт описывается словами «ХОЧУ КАК ХЕДХАНТЕР ТОЛЬКО С БЛОКЧЕЙНОМ И ГЕОЛОКАЦИЕЙ».
Требования к подобному документу простые: ясность выражения мысли, отсутствие ненужных деталей (дабы не затуманивать идею и не влезать раньше времени в проектирование) и, самое главное, честность - если вам предстоит какая-то рискованная жопа, про это стоит начать говорить как можно раньше.
Я лично называю документы этого типа концепцией, широкие народные массы называют это по-разному - от «брифа» до «ТЗ». И это нормально: по факту, идея может рождаться на стороне заказчика и дозревать потом в руках разработчика, по ходу пьесы принимая формат самых разных документов.
Роль вторая - постановка задачи. Когда вы спроектировали продукт, то вам надо объяснить вашим разработчикам (а иногда - и самому себе), что именно вы хотите получить в итоге. Тут есть важная хитрость - степень подробности описания будет сильно зависеть от степени доверия команде: если крутому, дружественно настроенному тимлиду может быть достаточно описания уровня «вот нарисованные интерфейсы, вот общее описание процессов, давай фигачить и разбираться вместе с мелочами в процессе», то горе-разработчику с фриланс.ру нужно будет нудно расписывать, а что же вы подразумеваете под словами «при нажатии на кнопку покупки происходит добавление товара в корзину».
Схожая тема касается и формальности документа - она будет зависеть от ваших взаимоотношений с командой. Если вы работаете со своей командой, то можно использовать емкие, простые описания, если же у вас куча сменяющих друг друга подрядчиков, то не обойтись без формального, системного документа со всякими «Историями изменений», «Словарем терминов» и прочей бюрократической мутью, единственная цель которой - в случае чего схватить зарвавшегося подрядчика за яйца (об этом, впрочем, не сегодня).
Требования к этой группе документов такие: однозначность и достаточность (у вашего конкретного разработчика, который прочтет документ, не должно остаться к вам важных вопросов), а также читабельность (как правило, описания продуктов большие, и если вы сделаете документ мутным и запутанным - на пользу это никому не пойдет).
Именно эту группу документов чаще всего называют техническим заданием, потому что вся она действительно представляет собой задание на разработку. И я с этой позицией полностью согласен.
Нам осталось поговорить про третью и четвертую роли документации, а также про еще кое-какие мелочи (например, кто все это должен писать). Об этом я расскажу вам завтра, чтобы не травмировать ваш ДЕНЬ РОССИИ огромной простыней из текста.
#вашидокументы
Поэтому во исполнение Федеральной программы по соблюдению здравого смысла (которую я выдумал только что) я хочу призвать вас отвлечься от ТЗ и задуматься - а какую роль вообще выполняют всякие описательные документы в процессе разработки?
Этих ролей не так уж и много - всего четыре штуки.
Роль первая - выражение идеи. Когда вы придумываете продукт (будь вы заказчик или разработчик), то вы рано или поздно должны сформулировать его общую идею и донести ее до окружающих - заказчика, подрядчика, команды, начальства, самого себя, в конце концов. Хорошо, если идея будет сопровождаться еще и описанием решаемой задачи - это облегчает понимание того, нахрена вы все тут собрались. Это полезно делать как с чисто коммуникационной точки зрения, чтобы все были в курсе, так и с точки зрения планирования - сложно составлять какие-либо дорожные карты, когда ваш продукт описывается словами «ХОЧУ КАК ХЕДХАНТЕР ТОЛЬКО С БЛОКЧЕЙНОМ И ГЕОЛОКАЦИЕЙ».
Требования к подобному документу простые: ясность выражения мысли, отсутствие ненужных деталей (дабы не затуманивать идею и не влезать раньше времени в проектирование) и, самое главное, честность - если вам предстоит какая-то рискованная жопа, про это стоит начать говорить как можно раньше.
Я лично называю документы этого типа концепцией, широкие народные массы называют это по-разному - от «брифа» до «ТЗ». И это нормально: по факту, идея может рождаться на стороне заказчика и дозревать потом в руках разработчика, по ходу пьесы принимая формат самых разных документов.
Роль вторая - постановка задачи. Когда вы спроектировали продукт, то вам надо объяснить вашим разработчикам (а иногда - и самому себе), что именно вы хотите получить в итоге. Тут есть важная хитрость - степень подробности описания будет сильно зависеть от степени доверия команде: если крутому, дружественно настроенному тимлиду может быть достаточно описания уровня «вот нарисованные интерфейсы, вот общее описание процессов, давай фигачить и разбираться вместе с мелочами в процессе», то горе-разработчику с фриланс.ру нужно будет нудно расписывать, а что же вы подразумеваете под словами «при нажатии на кнопку покупки происходит добавление товара в корзину».
Схожая тема касается и формальности документа - она будет зависеть от ваших взаимоотношений с командой. Если вы работаете со своей командой, то можно использовать емкие, простые описания, если же у вас куча сменяющих друг друга подрядчиков, то не обойтись без формального, системного документа со всякими «Историями изменений», «Словарем терминов» и прочей бюрократической мутью, единственная цель которой - в случае чего схватить зарвавшегося подрядчика за яйца (об этом, впрочем, не сегодня).
Требования к этой группе документов такие: однозначность и достаточность (у вашего конкретного разработчика, который прочтет документ, не должно остаться к вам важных вопросов), а также читабельность (как правило, описания продуктов большие, и если вы сделаете документ мутным и запутанным - на пользу это никому не пойдет).
Именно эту группу документов чаще всего называют техническим заданием, потому что вся она действительно представляет собой задание на разработку. И я с этой позицией полностью согласен.
Нам осталось поговорить про третью и четвертую роли документации, а также про еще кое-какие мелочи (например, кто все это должен писать). Об этом я расскажу вам завтра, чтобы не травмировать ваш ДЕНЬ РОССИИ огромной простыней из текста.
#вашидокументы
Третья роль документов - это хранение и передача знаний. Когда вы что-то разработали, то важно задокументировать результат, чтобы потом было понятно, как все устроено. С этим в разработке всегда большая беда: подобная описательная документация или вообще не ведется (ибо некому и некогда), или же в ее роли используется тот же документ, который применялся для постановки задачи - то самое ТЗ в моей терминологии.
Это однозначно плохая практика: ТЗ может не включать в себя технические детали, которые не важны на момент постановки задачи, но важны с точки зрения развития продукта (например, описание каких-то хитрых внутренних процессов или базы данных), а еще продукт в процессе разработки может сильно поменяться.
Я всегда ратую за то, чтобы процесс разработки включал в себя составление спецификаций - документа, который описывает уже сделанный продукт. Чаще всего этот документ составляется на основе ТЗ, но пишется уже после разработки и включает в себя больше деталей и актуальных нюансов. Если в дальнейшем происходит доработка продукта, то этот документ обогащается новыми разделами и деталями, но сам он остается единым.
Требования к спецификациям: однозначность, полнота (обратите внимание - не достаточность для конкретного разработчика, а полное описание всех деталей!), системность (описание всех аспектов продукта - от интерфейсов до функциональности) и читабельность.
Четвертая роль документов - это формальная фиксация договоренностей с заказчиком или подрядчиком. Тут возможны многие варианты - к договору может быть приложено как реальное ТЗ, так и формализованная концепция, а то и просто невнятная декларация о намерениях. Когда я работал с госпроектами, в норме вещей было взять нормальное ТЗ для разработчиков, отдать его в специальную контору и получить обратно лютый пакет документов на государственном языке, с которым было безумно тяжело работать, но которое хорошо укладывалось в бюрократические процедуры госзакупок.
Форматов оформления масса, и я бы выделил два главных требования к ним: соответствие ситуации (работаете с госами - подавай документацию по ГОСТу, работаете с лояльным заказчиком - расслабься и описывай общую дорожную карту) и юридически выверенный язык, поскольку этот документ все же важен с точки зрения делопроизводства и несет юридическую силу.
Тут, впрочем, будьте внимательны: как показывает моя жизнь, классное «юридическое» ТЗ является гарантией в суде, но не является гарантией качественной разработки или адекватного поведения заказчика. Да и вообще никакое ТЗ не является гарантией хорошей разработки, потому что отдельные чудилы ничего не читают и читать не собираются. Поэтому помните про Agile-манифест и заморачивайтесь не документами, а людьми.
P.S. А еще документы не обязательно должны быть текстовыми - это могут быть, например, изображения интерфейсов или схемы бизнес-процессов. Более того, одна и та же картинка может выполнять разные роли: макет интерфейса может быть иллюстрацией идеи, постановкой задачи для верстальщика, входить в состав спецификаций и прикладываться к договору. Главное - соблюдать требования, которые я описал выше.
P.P.S. Еще я вам пообещал сказать о том, кто же должен писать ТЗ. Ответ такой: да кто угодно. Главное, чтобы писать умел и свое дело знал.
P.P.P.S. Ладно-ладно, почти шучу. Вопрос про писателей документов настолько нажористый, что я про него еще отдельно расскажу.
#вашидокументы
Это однозначно плохая практика: ТЗ может не включать в себя технические детали, которые не важны на момент постановки задачи, но важны с точки зрения развития продукта (например, описание каких-то хитрых внутренних процессов или базы данных), а еще продукт в процессе разработки может сильно поменяться.
Я всегда ратую за то, чтобы процесс разработки включал в себя составление спецификаций - документа, который описывает уже сделанный продукт. Чаще всего этот документ составляется на основе ТЗ, но пишется уже после разработки и включает в себя больше деталей и актуальных нюансов. Если в дальнейшем происходит доработка продукта, то этот документ обогащается новыми разделами и деталями, но сам он остается единым.
Требования к спецификациям: однозначность, полнота (обратите внимание - не достаточность для конкретного разработчика, а полное описание всех деталей!), системность (описание всех аспектов продукта - от интерфейсов до функциональности) и читабельность.
Четвертая роль документов - это формальная фиксация договоренностей с заказчиком или подрядчиком. Тут возможны многие варианты - к договору может быть приложено как реальное ТЗ, так и формализованная концепция, а то и просто невнятная декларация о намерениях. Когда я работал с госпроектами, в норме вещей было взять нормальное ТЗ для разработчиков, отдать его в специальную контору и получить обратно лютый пакет документов на государственном языке, с которым было безумно тяжело работать, но которое хорошо укладывалось в бюрократические процедуры госзакупок.
Форматов оформления масса, и я бы выделил два главных требования к ним: соответствие ситуации (работаете с госами - подавай документацию по ГОСТу, работаете с лояльным заказчиком - расслабься и описывай общую дорожную карту) и юридически выверенный язык, поскольку этот документ все же важен с точки зрения делопроизводства и несет юридическую силу.
Тут, впрочем, будьте внимательны: как показывает моя жизнь, классное «юридическое» ТЗ является гарантией в суде, но не является гарантией качественной разработки или адекватного поведения заказчика. Да и вообще никакое ТЗ не является гарантией хорошей разработки, потому что отдельные чудилы ничего не читают и читать не собираются. Поэтому помните про Agile-манифест и заморачивайтесь не документами, а людьми.
P.S. А еще документы не обязательно должны быть текстовыми - это могут быть, например, изображения интерфейсов или схемы бизнес-процессов. Более того, одна и та же картинка может выполнять разные роли: макет интерфейса может быть иллюстрацией идеи, постановкой задачи для верстальщика, входить в состав спецификаций и прикладываться к договору. Главное - соблюдать требования, которые я описал выше.
P.P.S. Еще я вам пообещал сказать о том, кто же должен писать ТЗ. Ответ такой: да кто угодно. Главное, чтобы писать умел и свое дело знал.
P.P.P.S. Ладно-ладно, почти шучу. Вопрос про писателей документов настолько нажористый, что я про него еще отдельно расскажу.
#вашидокументы
Про ТЗ вот вспомнил пятничную историю.
Жила-была одна контора разработчиков, которая сидела по соседству с нами и была нашим партнером. Ее владелец был колоритным армянином, похожим на хорошо откормленного Железного человека, и обожал мне повторять при встрече: «ЛЁХА ТВОЕ ТЗ ГОВНО». Я сперва деликатно отвечал, что-де, а в чем именно говно и давайте разберемся; потом просто злился; потом молчал; потом уже автоматом отвечал ему «ДА САМ ТЫ ГОВНО», а потом произошло вот что.
Как-то раз написал я ТЗ на личный кабинет одного пенсионного фонда и отправил его тем самым разработчикам. Они взяли ТЗ в работу и пообещали выдать результат через 3 недели - допустим, к 31 февраля.
И вот на календаре 30 февраля. Вечер. Падает снег, все дела, а у меня раздается звонок от тимлида этой партнерской конторы - типа, Лёха, заходи, надо кое-что обсудить важное.
Захожу. Тимлид показывает мне на мониторе 12 страницу ТЗ и говорит такой: «ЛЁХА Я НЕ ПОНИМАЮ КАК ЭТО ДОЛЖНО РАБОТАТЬ». Я ему в ответ говорю - как так, Миш, это же 12 страница, и тут все просто - а у тебя впереди еще 56 страниц, и там все куда сложнее.
Он такой: «НУ ВОТ Я НАЧАЛ ЧИТАТЬ И НЕ ПОНИМАЮ».
Я ему: Мишаня, а как ты только начал читать-то? Ты ничего не делал эти 3 недели, что ли?
Он такой: «ДЕЛАЛ» - и показывает кусок сырой херни, которая отдаленно похожа на сделанный мной личный кабинет.
Я ему: Миш, а Миш, а ты ТЗ вообще читал, прежде чем делать?
Он такой: «НЕТ», говорит.
Я молчу, уставившись в монитор как баран. И тут матерый программист Миша выдает шикарную фразу: «ТУТ МНОГО ТЕКСТА А ЛЮДИ ВООБЩЕ ПРИВЫКЛИ КАРТИНКАМИ МЫСЛИТЬ».
Еще раз: программист структурированного текста испугался. Текста. Программист. Подумать только.
В этот момент я четко понял, почему мое хорошее, чистое и опрятное ТЗ они считали говном - они его просто не читали.
Так я вывел простую мысль, достойную Agile-манифеста: хреновому разработчику напиши мало - ничего не сделает, напиши много - не прочитает и все равно ничего не сделает. Просто не надо хреновых разработчиков брать.
Потом эта контора как-то случайно взяла на должность программиста курьера, ошибшегося дверью, но это уже другая история.
#изкрестьянскогобыта #вашидокументы
Жила-была одна контора разработчиков, которая сидела по соседству с нами и была нашим партнером. Ее владелец был колоритным армянином, похожим на хорошо откормленного Железного человека, и обожал мне повторять при встрече: «ЛЁХА ТВОЕ ТЗ ГОВНО». Я сперва деликатно отвечал, что-де, а в чем именно говно и давайте разберемся; потом просто злился; потом молчал; потом уже автоматом отвечал ему «ДА САМ ТЫ ГОВНО», а потом произошло вот что.
Как-то раз написал я ТЗ на личный кабинет одного пенсионного фонда и отправил его тем самым разработчикам. Они взяли ТЗ в работу и пообещали выдать результат через 3 недели - допустим, к 31 февраля.
И вот на календаре 30 февраля. Вечер. Падает снег, все дела, а у меня раздается звонок от тимлида этой партнерской конторы - типа, Лёха, заходи, надо кое-что обсудить важное.
Захожу. Тимлид показывает мне на мониторе 12 страницу ТЗ и говорит такой: «ЛЁХА Я НЕ ПОНИМАЮ КАК ЭТО ДОЛЖНО РАБОТАТЬ». Я ему в ответ говорю - как так, Миш, это же 12 страница, и тут все просто - а у тебя впереди еще 56 страниц, и там все куда сложнее.
Он такой: «НУ ВОТ Я НАЧАЛ ЧИТАТЬ И НЕ ПОНИМАЮ».
Я ему: Мишаня, а как ты только начал читать-то? Ты ничего не делал эти 3 недели, что ли?
Он такой: «ДЕЛАЛ» - и показывает кусок сырой херни, которая отдаленно похожа на сделанный мной личный кабинет.
Я ему: Миш, а Миш, а ты ТЗ вообще читал, прежде чем делать?
Он такой: «НЕТ», говорит.
Я молчу, уставившись в монитор как баран. И тут матерый программист Миша выдает шикарную фразу: «ТУТ МНОГО ТЕКСТА А ЛЮДИ ВООБЩЕ ПРИВЫКЛИ КАРТИНКАМИ МЫСЛИТЬ».
Еще раз: программист структурированного текста испугался. Текста. Программист. Подумать только.
В этот момент я четко понял, почему мое хорошее, чистое и опрятное ТЗ они считали говном - они его просто не читали.
Так я вывел простую мысль, достойную Agile-манифеста: хреновому разработчику напиши мало - ничего не сделает, напиши много - не прочитает и все равно ничего не сделает. Просто не надо хреновых разработчиков брать.
Потом эта контора как-то случайно взяла на должность программиста курьера, ошибшегося дверью, но это уже другая история.
#изкрестьянскогобыта #вашидокументы