Так вот, про ТЗ. Как вы заметили по голосованию выше, под ТЗ все подразумевают совершенно разное, и дискуссия «что такое ТЗ» неизбежно вырождается в спор глухого с тупым - очень сложно сойтись в своих оценках, когда ты даже под одними и теми же словами понимаешь разное.
Поэтому во исполнение Федеральной программы по соблюдению здравого смысла (которую я выдумал только что) я хочу призвать вас отвлечься от ТЗ и задуматься - а какую роль вообще выполняют всякие описательные документы в процессе разработки?
Этих ролей не так уж и много - всего четыре штуки.
Роль первая - выражение идеи. Когда вы придумываете продукт (будь вы заказчик или разработчик), то вы рано или поздно должны сформулировать его общую идею и донести ее до окружающих - заказчика, подрядчика, команды, начальства, самого себя, в конце концов. Хорошо, если идея будет сопровождаться еще и описанием решаемой задачи - это облегчает понимание того, нахрена вы все тут собрались. Это полезно делать как с чисто коммуникационной точки зрения, чтобы все были в курсе, так и с точки зрения планирования - сложно составлять какие-либо дорожные карты, когда ваш продукт описывается словами «ХОЧУ КАК ХЕДХАНТЕР ТОЛЬКО С БЛОКЧЕЙНОМ И ГЕОЛОКАЦИЕЙ».
Требования к подобному документу простые: ясность выражения мысли, отсутствие ненужных деталей (дабы не затуманивать идею и не влезать раньше времени в проектирование) и, самое главное, честность - если вам предстоит какая-то рискованная жопа, про это стоит начать говорить как можно раньше.
Я лично называю документы этого типа концепцией, широкие народные массы называют это по-разному - от «брифа» до «ТЗ». И это нормально: по факту, идея может рождаться на стороне заказчика и дозревать потом в руках разработчика, по ходу пьесы принимая формат самых разных документов.
Роль вторая - постановка задачи. Когда вы спроектировали продукт, то вам надо объяснить вашим разработчикам (а иногда - и самому себе), что именно вы хотите получить в итоге. Тут есть важная хитрость - степень подробности описания будет сильно зависеть от степени доверия команде: если крутому, дружественно настроенному тимлиду может быть достаточно описания уровня «вот нарисованные интерфейсы, вот общее описание процессов, давай фигачить и разбираться вместе с мелочами в процессе», то горе-разработчику с фриланс.ру нужно будет нудно расписывать, а что же вы подразумеваете под словами «при нажатии на кнопку покупки происходит добавление товара в корзину».
Схожая тема касается и формальности документа - она будет зависеть от ваших взаимоотношений с командой. Если вы работаете со своей командой, то можно использовать емкие, простые описания, если же у вас куча сменяющих друг друга подрядчиков, то не обойтись без формального, системного документа со всякими «Историями изменений», «Словарем терминов» и прочей бюрократической мутью, единственная цель которой - в случае чего схватить зарвавшегося подрядчика за яйца (об этом, впрочем, не сегодня).
Требования к этой группе документов такие: однозначность и достаточность (у вашего конкретного разработчика, который прочтет документ, не должно остаться к вам важных вопросов), а также читабельность (как правило, описания продуктов большие, и если вы сделаете документ мутным и запутанным - на пользу это никому не пойдет).
Именно эту группу документов чаще всего называют техническим заданием, потому что вся она действительно представляет собой задание на разработку. И я с этой позицией полностью согласен.
Нам осталось поговорить про третью и четвертую роли документации, а также про еще кое-какие мелочи (например, кто все это должен писать). Об этом я расскажу вам завтра, чтобы не травмировать ваш ДЕНЬ РОССИИ огромной простыней из текста.
#вашидокументы
Поэтому во исполнение Федеральной программы по соблюдению здравого смысла (которую я выдумал только что) я хочу призвать вас отвлечься от ТЗ и задуматься - а какую роль вообще выполняют всякие описательные документы в процессе разработки?
Этих ролей не так уж и много - всего четыре штуки.
Роль первая - выражение идеи. Когда вы придумываете продукт (будь вы заказчик или разработчик), то вы рано или поздно должны сформулировать его общую идею и донести ее до окружающих - заказчика, подрядчика, команды, начальства, самого себя, в конце концов. Хорошо, если идея будет сопровождаться еще и описанием решаемой задачи - это облегчает понимание того, нахрена вы все тут собрались. Это полезно делать как с чисто коммуникационной точки зрения, чтобы все были в курсе, так и с точки зрения планирования - сложно составлять какие-либо дорожные карты, когда ваш продукт описывается словами «ХОЧУ КАК ХЕДХАНТЕР ТОЛЬКО С БЛОКЧЕЙНОМ И ГЕОЛОКАЦИЕЙ».
Требования к подобному документу простые: ясность выражения мысли, отсутствие ненужных деталей (дабы не затуманивать идею и не влезать раньше времени в проектирование) и, самое главное, честность - если вам предстоит какая-то рискованная жопа, про это стоит начать говорить как можно раньше.
Я лично называю документы этого типа концепцией, широкие народные массы называют это по-разному - от «брифа» до «ТЗ». И это нормально: по факту, идея может рождаться на стороне заказчика и дозревать потом в руках разработчика, по ходу пьесы принимая формат самых разных документов.
Роль вторая - постановка задачи. Когда вы спроектировали продукт, то вам надо объяснить вашим разработчикам (а иногда - и самому себе), что именно вы хотите получить в итоге. Тут есть важная хитрость - степень подробности описания будет сильно зависеть от степени доверия команде: если крутому, дружественно настроенному тимлиду может быть достаточно описания уровня «вот нарисованные интерфейсы, вот общее описание процессов, давай фигачить и разбираться вместе с мелочами в процессе», то горе-разработчику с фриланс.ру нужно будет нудно расписывать, а что же вы подразумеваете под словами «при нажатии на кнопку покупки происходит добавление товара в корзину».
Схожая тема касается и формальности документа - она будет зависеть от ваших взаимоотношений с командой. Если вы работаете со своей командой, то можно использовать емкие, простые описания, если же у вас куча сменяющих друг друга подрядчиков, то не обойтись без формального, системного документа со всякими «Историями изменений», «Словарем терминов» и прочей бюрократической мутью, единственная цель которой - в случае чего схватить зарвавшегося подрядчика за яйца (об этом, впрочем, не сегодня).
Требования к этой группе документов такие: однозначность и достаточность (у вашего конкретного разработчика, который прочтет документ, не должно остаться к вам важных вопросов), а также читабельность (как правило, описания продуктов большие, и если вы сделаете документ мутным и запутанным - на пользу это никому не пойдет).
Именно эту группу документов чаще всего называют техническим заданием, потому что вся она действительно представляет собой задание на разработку. И я с этой позицией полностью согласен.
Нам осталось поговорить про третью и четвертую роли документации, а также про еще кое-какие мелочи (например, кто все это должен писать). Об этом я расскажу вам завтра, чтобы не травмировать ваш ДЕНЬ РОССИИ огромной простыней из текста.
#вашидокументы
Третья роль документов - это хранение и передача знаний. Когда вы что-то разработали, то важно задокументировать результат, чтобы потом было понятно, как все устроено. С этим в разработке всегда большая беда: подобная описательная документация или вообще не ведется (ибо некому и некогда), или же в ее роли используется тот же документ, который применялся для постановки задачи - то самое ТЗ в моей терминологии.
Это однозначно плохая практика: ТЗ может не включать в себя технические детали, которые не важны на момент постановки задачи, но важны с точки зрения развития продукта (например, описание каких-то хитрых внутренних процессов или базы данных), а еще продукт в процессе разработки может сильно поменяться.
Я всегда ратую за то, чтобы процесс разработки включал в себя составление спецификаций - документа, который описывает уже сделанный продукт. Чаще всего этот документ составляется на основе ТЗ, но пишется уже после разработки и включает в себя больше деталей и актуальных нюансов. Если в дальнейшем происходит доработка продукта, то этот документ обогащается новыми разделами и деталями, но сам он остается единым.
Требования к спецификациям: однозначность, полнота (обратите внимание - не достаточность для конкретного разработчика, а полное описание всех деталей!), системность (описание всех аспектов продукта - от интерфейсов до функциональности) и читабельность.
Четвертая роль документов - это формальная фиксация договоренностей с заказчиком или подрядчиком. Тут возможны многие варианты - к договору может быть приложено как реальное ТЗ, так и формализованная концепция, а то и просто невнятная декларация о намерениях. Когда я работал с госпроектами, в норме вещей было взять нормальное ТЗ для разработчиков, отдать его в специальную контору и получить обратно лютый пакет документов на государственном языке, с которым было безумно тяжело работать, но которое хорошо укладывалось в бюрократические процедуры госзакупок.
Форматов оформления масса, и я бы выделил два главных требования к ним: соответствие ситуации (работаете с госами - подавай документацию по ГОСТу, работаете с лояльным заказчиком - расслабься и описывай общую дорожную карту) и юридически выверенный язык, поскольку этот документ все же важен с точки зрения делопроизводства и несет юридическую силу.
Тут, впрочем, будьте внимательны: как показывает моя жизнь, классное «юридическое» ТЗ является гарантией в суде, но не является гарантией качественной разработки или адекватного поведения заказчика. Да и вообще никакое ТЗ не является гарантией хорошей разработки, потому что отдельные чудилы ничего не читают и читать не собираются. Поэтому помните про Agile-манифест и заморачивайтесь не документами, а людьми.
P.S. А еще документы не обязательно должны быть текстовыми - это могут быть, например, изображения интерфейсов или схемы бизнес-процессов. Более того, одна и та же картинка может выполнять разные роли: макет интерфейса может быть иллюстрацией идеи, постановкой задачи для верстальщика, входить в состав спецификаций и прикладываться к договору. Главное - соблюдать требования, которые я описал выше.
P.P.S. Еще я вам пообещал сказать о том, кто же должен писать ТЗ. Ответ такой: да кто угодно. Главное, чтобы писать умел и свое дело знал.
P.P.P.S. Ладно-ладно, почти шучу. Вопрос про писателей документов настолько нажористый, что я про него еще отдельно расскажу.
#вашидокументы
Это однозначно плохая практика: ТЗ может не включать в себя технические детали, которые не важны на момент постановки задачи, но важны с точки зрения развития продукта (например, описание каких-то хитрых внутренних процессов или базы данных), а еще продукт в процессе разработки может сильно поменяться.
Я всегда ратую за то, чтобы процесс разработки включал в себя составление спецификаций - документа, который описывает уже сделанный продукт. Чаще всего этот документ составляется на основе ТЗ, но пишется уже после разработки и включает в себя больше деталей и актуальных нюансов. Если в дальнейшем происходит доработка продукта, то этот документ обогащается новыми разделами и деталями, но сам он остается единым.
Требования к спецификациям: однозначность, полнота (обратите внимание - не достаточность для конкретного разработчика, а полное описание всех деталей!), системность (описание всех аспектов продукта - от интерфейсов до функциональности) и читабельность.
Четвертая роль документов - это формальная фиксация договоренностей с заказчиком или подрядчиком. Тут возможны многие варианты - к договору может быть приложено как реальное ТЗ, так и формализованная концепция, а то и просто невнятная декларация о намерениях. Когда я работал с госпроектами, в норме вещей было взять нормальное ТЗ для разработчиков, отдать его в специальную контору и получить обратно лютый пакет документов на государственном языке, с которым было безумно тяжело работать, но которое хорошо укладывалось в бюрократические процедуры госзакупок.
Форматов оформления масса, и я бы выделил два главных требования к ним: соответствие ситуации (работаете с госами - подавай документацию по ГОСТу, работаете с лояльным заказчиком - расслабься и описывай общую дорожную карту) и юридически выверенный язык, поскольку этот документ все же важен с точки зрения делопроизводства и несет юридическую силу.
Тут, впрочем, будьте внимательны: как показывает моя жизнь, классное «юридическое» ТЗ является гарантией в суде, но не является гарантией качественной разработки или адекватного поведения заказчика. Да и вообще никакое ТЗ не является гарантией хорошей разработки, потому что отдельные чудилы ничего не читают и читать не собираются. Поэтому помните про Agile-манифест и заморачивайтесь не документами, а людьми.
P.S. А еще документы не обязательно должны быть текстовыми - это могут быть, например, изображения интерфейсов или схемы бизнес-процессов. Более того, одна и та же картинка может выполнять разные роли: макет интерфейса может быть иллюстрацией идеи, постановкой задачи для верстальщика, входить в состав спецификаций и прикладываться к договору. Главное - соблюдать требования, которые я описал выше.
P.P.S. Еще я вам пообещал сказать о том, кто же должен писать ТЗ. Ответ такой: да кто угодно. Главное, чтобы писать умел и свое дело знал.
P.P.P.S. Ладно-ладно, почти шучу. Вопрос про писателей документов настолько нажористый, что я про него еще отдельно расскажу.
#вашидокументы
А вот давайте про пустые состояния интерфейсов поговорим, но сперва поиграем в картинки и гражданское голосование.
Есть два интерфейса. Куда сами сядете, куда пользователя посадите?
Есть два интерфейса. Куда сами сядете, куда пользователя посадите?
Отвечайте на вопрос, поставленный выше!
anonymous poll
Странный вопрос, но мне нравится вариант с кнопкой – 148
👍👍👍👍👍👍👍 49%
Я не понял сути шутки, но мне нравится вариант без кнопки – 76
👍👍👍👍 25%
Лёха, хорош уже с этими шутками, ты бы еще про полотенце на полу спросил – 41
👍👍 13%
Я отказываюсь отвечать, зовите адвоката – 40
👍👍 13%
👥 305 people voted so far.
anonymous poll
Странный вопрос, но мне нравится вариант с кнопкой – 148
👍👍👍👍👍👍👍 49%
Я не понял сути шутки, но мне нравится вариант без кнопки – 76
👍👍👍👍 25%
Лёха, хорош уже с этими шутками, ты бы еще про полотенце на полу спросил – 41
👍👍 13%
Я отказываюсь отвечать, зовите адвоката – 40
👍👍 13%
👥 305 people voted so far.
А вы хороши - в основной своей массе проголосовали за вариант корзины с кнопкой. Хороши, потому что он и вправду эффективный, как подсказывает мне моя крестьянская жилка.
Ведь пользователь - он что? Он, подобно врубелевскому демону, лихо летает над интерфейсами и хочет решать свои задачи максимально быстро и максимально не задумываясь. Оп! - и пользователь зашел в интернет-магазин. Оп! - и пользователь нашел нужный ему товар. Оп! - и пользователь заказал товар. Оп! - и товар уже мчит к пользователю в руки. И так далее. Пользователь зрит перед собою цель - и летит к ней.
Что же происходит, когда пользователь попадает на экран, где его не ждут - например, на экран пустой корзины?
Дурной UX-дизайнер скажет: «А НИЧЕГО НЕ ПРОИСХОДИТ» - и намалюет интерфейс, где, натурально, ничего не происходит. Например, сделает белый экран с надписью «Ваша корзина пуста». Особо отмороженный дизайнер просто сбацает полностью белый, как холодильник, экран. Как бы человеколюбивый дизайнер сделает экран с надписью «Добавьте товар, чтобы в корзину добавился товар». И все.
И это белое полотно для нашего пользователя - метущегося по сайту врубелевского демона - будет сродни бетонной стене: он столкнется (жестко, до хруста костей!) с пустым экраном и не будет понимать, что делать дальше. Будто бы само мироздание в этот момент скажет ему: «О пользователь! У тебя была твоя цель, ты находился в контексте и логике пользовательской задачи и перемещался в веселии своем с экрана на экран! У тебя было это - и прошло. Теперь смотри на белый экран и думай сам, что тебе делать дальше. Я тебе более не помощник».
И что сделает пользователь? Что угодно. Возможно, он нажмет «Назад». Или перейдет на главный экран. Или будет копаться в меню. Или вообще свалит с сайта, уедет на Тибет и примет там секретное дао Дракона. Кто знает?
И вот это что угодно - это кошмарный сон для любого проектировщика, который стремится удерживать пользователя в контексте задачи, не заставляет его излишне думать, направляет его к продуктивному сценарию и не надеется на волю случая, дизайнерский фантом, юзабилити-пшик.
Вдумчивый, мудрый UX-дизайнер относится к пустым состояниям интерфейса не как к ничтожному месту, но как к восхитительно пустому холсту, на который еще предстоит нанести полезный рисунок и наладить полезное взаимодействие.
Такой дизайнер, как минимум, оценивает - а как пользователь воспримет пустой интерфейс. Он просто пройдет мимо и не будет отвлекаться от своей задачи? Тогда пользователя можно особо не трогать, достаточно лишь обозначить, почему это место пустует и как оно будет заполнено. Пользователь налетит на пустое состояние как на непреодолимое препятствие? Тогда пользователю нужно не просто объяснить, что это за пустое место - но дать ему понятные инструменты для продолжения работы в его контексте.
В руках мудрого дизайнера пустая корзина обзаведется кнопкой «продолжить покупки», чтобы пользователь не терял контекст работы и не думал, что его бросили на произвол судьбы. Возможно, пустая корзина обзаведется превьюшками товаров, которые пользователь мог бы положить в эту корзину - причем они будут зависеть от предполагаемой цели пользователя. А возможно, там вообще будет что-то третье - нестерпимо полезное и оригинальное.
В любом случае это не будет стена, конец, тепловая смерть пользователя от демотивации, а будет жизнь, радость, достижение цели, вселенская гармония. Это будет рай свободы нашего врубелевского демона.
Ради того и живем.
#изкрестьянскогобыта
Ведь пользователь - он что? Он, подобно врубелевскому демону, лихо летает над интерфейсами и хочет решать свои задачи максимально быстро и максимально не задумываясь. Оп! - и пользователь зашел в интернет-магазин. Оп! - и пользователь нашел нужный ему товар. Оп! - и пользователь заказал товар. Оп! - и товар уже мчит к пользователю в руки. И так далее. Пользователь зрит перед собою цель - и летит к ней.
Что же происходит, когда пользователь попадает на экран, где его не ждут - например, на экран пустой корзины?
Дурной UX-дизайнер скажет: «А НИЧЕГО НЕ ПРОИСХОДИТ» - и намалюет интерфейс, где, натурально, ничего не происходит. Например, сделает белый экран с надписью «Ваша корзина пуста». Особо отмороженный дизайнер просто сбацает полностью белый, как холодильник, экран. Как бы человеколюбивый дизайнер сделает экран с надписью «Добавьте товар, чтобы в корзину добавился товар». И все.
И это белое полотно для нашего пользователя - метущегося по сайту врубелевского демона - будет сродни бетонной стене: он столкнется (жестко, до хруста костей!) с пустым экраном и не будет понимать, что делать дальше. Будто бы само мироздание в этот момент скажет ему: «О пользователь! У тебя была твоя цель, ты находился в контексте и логике пользовательской задачи и перемещался в веселии своем с экрана на экран! У тебя было это - и прошло. Теперь смотри на белый экран и думай сам, что тебе делать дальше. Я тебе более не помощник».
И что сделает пользователь? Что угодно. Возможно, он нажмет «Назад». Или перейдет на главный экран. Или будет копаться в меню. Или вообще свалит с сайта, уедет на Тибет и примет там секретное дао Дракона. Кто знает?
И вот это что угодно - это кошмарный сон для любого проектировщика, который стремится удерживать пользователя в контексте задачи, не заставляет его излишне думать, направляет его к продуктивному сценарию и не надеется на волю случая, дизайнерский фантом, юзабилити-пшик.
Вдумчивый, мудрый UX-дизайнер относится к пустым состояниям интерфейса не как к ничтожному месту, но как к восхитительно пустому холсту, на который еще предстоит нанести полезный рисунок и наладить полезное взаимодействие.
Такой дизайнер, как минимум, оценивает - а как пользователь воспримет пустой интерфейс. Он просто пройдет мимо и не будет отвлекаться от своей задачи? Тогда пользователя можно особо не трогать, достаточно лишь обозначить, почему это место пустует и как оно будет заполнено. Пользователь налетит на пустое состояние как на непреодолимое препятствие? Тогда пользователю нужно не просто объяснить, что это за пустое место - но дать ему понятные инструменты для продолжения работы в его контексте.
В руках мудрого дизайнера пустая корзина обзаведется кнопкой «продолжить покупки», чтобы пользователь не терял контекст работы и не думал, что его бросили на произвол судьбы. Возможно, пустая корзина обзаведется превьюшками товаров, которые пользователь мог бы положить в эту корзину - причем они будут зависеть от предполагаемой цели пользователя. А возможно, там вообще будет что-то третье - нестерпимо полезное и оригинальное.
В любом случае это не будет стена, конец, тепловая смерть пользователя от демотивации, а будет жизнь, радость, достижение цели, вселенская гармония. Это будет рай свободы нашего врубелевского демона.
Ради того и живем.
#изкрестьянскогобыта
А, забыл сказать: скриншоты корзин из голосования выше взяты с wildberries.ru и lamoda.ru, можете зайти и сравнить их сами.
Из-за леса, из-за гор к нам пришел БИСКВИТНЫЙ ДВОР - любимая в народе рубрика про откровенный хуикс.
Сегодня у нас в гостях кулинарный сервис Elementaree, приведенный к нам за шиворот Сашей Клименко (за что ей традиционный поклон и пожелания счастья, здоровья).
Поскольку этот сервис посвящен доставке еды, вот вам рецепт французского блюда Мерд-сюр-ан-пелль (что по-русски значит «Говно на лопате»):
1. Обещаете клиенту поменять время доставки «легко и удобно в личном кабинете»
2. После того, как клиент изменил время доставки - говорите ему: «ТЫ ЧО СОВСЕМ ПОЕХАЛ ЭТО МОЖНО СДЕЛАТЬ ТОЛЬКО ДО 16:00»
3. Когда клиент начинает залупаться, шлете его в пользовательское соглашение.
4. Поскольку геймификация - это модно, вовлекайте пользователя в русскую народную игру «Прятки с пользовательским соглашением». Правила такие: чем лучше пользовательское соглашение спряталось - тем лучше геймификация. Хорошая идея - спрятать пользовательское соглашение в жопу раздела «Система качества», который находится, в свою очередь, в жопе личного кабинета. Использовать при этом серый шрифт на белом фоне - клевая идея.
5. Не останавливайтесь! Спрячьте пункт про смену времени доставки в недра пользовательского соглашения, ведь мало пряток не бывает! Пусть ваш любимый пользователь не скучает!
6. Не привозите ничего пользователю и не пытайтесь ему помочь.
7. Поздравляем, Мерд-сюр-ан-пелль готово! Вы настоящий повар!
Иллюстрации авторства Саши Клименко вы найдете чуть ниже. Приятного аппетита!
Сегодня у нас в гостях кулинарный сервис Elementaree, приведенный к нам за шиворот Сашей Клименко (за что ей традиционный поклон и пожелания счастья, здоровья).
Поскольку этот сервис посвящен доставке еды, вот вам рецепт французского блюда Мерд-сюр-ан-пелль (что по-русски значит «Говно на лопате»):
1. Обещаете клиенту поменять время доставки «легко и удобно в личном кабинете»
2. После того, как клиент изменил время доставки - говорите ему: «ТЫ ЧО СОВСЕМ ПОЕХАЛ ЭТО МОЖНО СДЕЛАТЬ ТОЛЬКО ДО 16:00»
3. Когда клиент начинает залупаться, шлете его в пользовательское соглашение.
4. Поскольку геймификация - это модно, вовлекайте пользователя в русскую народную игру «Прятки с пользовательским соглашением». Правила такие: чем лучше пользовательское соглашение спряталось - тем лучше геймификация. Хорошая идея - спрятать пользовательское соглашение в жопу раздела «Система качества», который находится, в свою очередь, в жопе личного кабинета. Использовать при этом серый шрифт на белом фоне - клевая идея.
5. Не останавливайтесь! Спрячьте пункт про смену времени доставки в недра пользовательского соглашения, ведь мало пряток не бывает! Пусть ваш любимый пользователь не скучает!
6. Не привозите ничего пользователю и не пытайтесь ему помочь.
7. Поздравляем, Мерд-сюр-ан-пелль готово! Вы настоящий повар!
Иллюстрации авторства Саши Клименко вы найдете чуть ниже. Приятного аппетита!
Ну и - по традиции - расскажу, как лечится описанная выше херомантия (хотя все и так очевидно):
1. Не обещайте клиенту того, чего не сможете выполнить.
2. Если вы создаете геморные с точки зрения сервиса условия - сообщайте о них на видном месте.
3. В идеале, стройте свой сервис так, чтобы он помогал пользователю находить компромисс с геморными условиями. Это сложно, это больно, но в 95% случаев решаемо.
4. Не играйте с пользователем в прятки, только если он сам этого не захочет.
5. Не делайте говно на лопате.
Нарушение этих правил простительно только в том случае, если ваша бизнес-модель строится на прямом обмане клиентов, но это, сами понимаете, дело такое.
#бисквитныйдвор
P.S. Если у вас есть свои золотые кандидаты в БИСКВИТНЫЙ ДВОР, не ленитесь слать их мне в личку.
1. Не обещайте клиенту того, чего не сможете выполнить.
2. Если вы создаете геморные с точки зрения сервиса условия - сообщайте о них на видном месте.
3. В идеале, стройте свой сервис так, чтобы он помогал пользователю находить компромисс с геморными условиями. Это сложно, это больно, но в 95% случаев решаемо.
4. Не играйте с пользователем в прятки, только если он сам этого не захочет.
5. Не делайте говно на лопате.
Нарушение этих правил простительно только в том случае, если ваша бизнес-модель строится на прямом обмане клиентов, но это, сами понимаете, дело такое.
#бисквитныйдвор
P.S. Если у вас есть свои золотые кандидаты в БИСКВИТНЫЙ ДВОР, не ленитесь слать их мне в личку.
Про ТЗ вот вспомнил пятничную историю.
Жила-была одна контора разработчиков, которая сидела по соседству с нами и была нашим партнером. Ее владелец был колоритным армянином, похожим на хорошо откормленного Железного человека, и обожал мне повторять при встрече: «ЛЁХА ТВОЕ ТЗ ГОВНО». Я сперва деликатно отвечал, что-де, а в чем именно говно и давайте разберемся; потом просто злился; потом молчал; потом уже автоматом отвечал ему «ДА САМ ТЫ ГОВНО», а потом произошло вот что.
Как-то раз написал я ТЗ на личный кабинет одного пенсионного фонда и отправил его тем самым разработчикам. Они взяли ТЗ в работу и пообещали выдать результат через 3 недели - допустим, к 31 февраля.
И вот на календаре 30 февраля. Вечер. Падает снег, все дела, а у меня раздается звонок от тимлида этой партнерской конторы - типа, Лёха, заходи, надо кое-что обсудить важное.
Захожу. Тимлид показывает мне на мониторе 12 страницу ТЗ и говорит такой: «ЛЁХА Я НЕ ПОНИМАЮ КАК ЭТО ДОЛЖНО РАБОТАТЬ». Я ему в ответ говорю - как так, Миш, это же 12 страница, и тут все просто - а у тебя впереди еще 56 страниц, и там все куда сложнее.
Он такой: «НУ ВОТ Я НАЧАЛ ЧИТАТЬ И НЕ ПОНИМАЮ».
Я ему: Мишаня, а как ты только начал читать-то? Ты ничего не делал эти 3 недели, что ли?
Он такой: «ДЕЛАЛ» - и показывает кусок сырой херни, которая отдаленно похожа на сделанный мной личный кабинет.
Я ему: Миш, а Миш, а ты ТЗ вообще читал, прежде чем делать?
Он такой: «НЕТ», говорит.
Я молчу, уставившись в монитор как баран. И тут матерый программист Миша выдает шикарную фразу: «ТУТ МНОГО ТЕКСТА А ЛЮДИ ВООБЩЕ ПРИВЫКЛИ КАРТИНКАМИ МЫСЛИТЬ».
Еще раз: программист структурированного текста испугался. Текста. Программист. Подумать только.
В этот момент я четко понял, почему мое хорошее, чистое и опрятное ТЗ они считали говном - они его просто не читали.
Так я вывел простую мысль, достойную Agile-манифеста: хреновому разработчику напиши мало - ничего не сделает, напиши много - не прочитает и все равно ничего не сделает. Просто не надо хреновых разработчиков брать.
Потом эта контора как-то случайно взяла на должность программиста курьера, ошибшегося дверью, но это уже другая история.
#изкрестьянскогобыта #вашидокументы
Жила-была одна контора разработчиков, которая сидела по соседству с нами и была нашим партнером. Ее владелец был колоритным армянином, похожим на хорошо откормленного Железного человека, и обожал мне повторять при встрече: «ЛЁХА ТВОЕ ТЗ ГОВНО». Я сперва деликатно отвечал, что-де, а в чем именно говно и давайте разберемся; потом просто злился; потом молчал; потом уже автоматом отвечал ему «ДА САМ ТЫ ГОВНО», а потом произошло вот что.
Как-то раз написал я ТЗ на личный кабинет одного пенсионного фонда и отправил его тем самым разработчикам. Они взяли ТЗ в работу и пообещали выдать результат через 3 недели - допустим, к 31 февраля.
И вот на календаре 30 февраля. Вечер. Падает снег, все дела, а у меня раздается звонок от тимлида этой партнерской конторы - типа, Лёха, заходи, надо кое-что обсудить важное.
Захожу. Тимлид показывает мне на мониторе 12 страницу ТЗ и говорит такой: «ЛЁХА Я НЕ ПОНИМАЮ КАК ЭТО ДОЛЖНО РАБОТАТЬ». Я ему в ответ говорю - как так, Миш, это же 12 страница, и тут все просто - а у тебя впереди еще 56 страниц, и там все куда сложнее.
Он такой: «НУ ВОТ Я НАЧАЛ ЧИТАТЬ И НЕ ПОНИМАЮ».
Я ему: Мишаня, а как ты только начал читать-то? Ты ничего не делал эти 3 недели, что ли?
Он такой: «ДЕЛАЛ» - и показывает кусок сырой херни, которая отдаленно похожа на сделанный мной личный кабинет.
Я ему: Миш, а Миш, а ты ТЗ вообще читал, прежде чем делать?
Он такой: «НЕТ», говорит.
Я молчу, уставившись в монитор как баран. И тут матерый программист Миша выдает шикарную фразу: «ТУТ МНОГО ТЕКСТА А ЛЮДИ ВООБЩЕ ПРИВЫКЛИ КАРТИНКАМИ МЫСЛИТЬ».
Еще раз: программист структурированного текста испугался. Текста. Программист. Подумать только.
В этот момент я четко понял, почему мое хорошее, чистое и опрятное ТЗ они считали говном - они его просто не читали.
Так я вывел простую мысль, достойную Agile-манифеста: хреновому разработчику напиши мало - ничего не сделает, напиши много - не прочитает и все равно ничего не сделает. Просто не надо хреновых разработчиков брать.
Потом эта контора как-то случайно взяла на должность программиста курьера, ошибшегося дверью, но это уже другая история.
#изкрестьянскогобыта #вашидокументы
Давайте сбросим онлайн-оковы и предадимся утехам реальности (у меня еще запасен текст про проблемы параллельного проектирования всего на свете, но давайте этот праздник задротства оставим на выходные).
На фото выше вы видите летопись многодневной, тяжелой и изнуряющей битвы пользователей с владельцем продукта (представители управляющей компании, наверное, удивились бы такому титулу и обиженно переспросили бы «НИМА УЧУН ШУНДАЙ КИЛЯПСАН?»).
Короче, дело было так:
1. Жила-была Даниловская мануфактура с удобной лестницей. Все пользовались лестницей и были счастливы.
2. Управляющая компания в рамках Федеральной программы «Задай огня этим пешеходам» поставила кладбищенскую оградку в конце лестницы, какбе намекнув людям ходить в обход по набережной без тротуара и c кучей машин.
3. Народ пожал плечами и стал перешагивать через оградку.
4. Управляющая компания, возомнив себя шашечным гроссмейстером, сделала свой ход, выдвинув на переднюю позицию клумбу, которая нафиг заблокировала лестницу.
5. Народ пожал плечами и стал топтать газон.
6. Итог: вытоптанный газон, кладбищенская оградка, клумба в конце лестницы, пожимающий плечами народ. Вид, деликатно скажем, уродливее некуда. Если бы это был сайт, то он попал бы к нам в БИСКВИТНЫЙ ДВОР и мы долго и обидно смеялись бы над его фасоном.
Мораль I: ставьте дверь там, где ходят люди, а не там, где возжелалось вашей экспертной заднице. Иначе люди пробьют двери сами.
Мораль II: если понять, по какой логике управляющие компании занимаются благоустройством, то откроется сакральное знание, как вообще существует сайт galya.ru.
#хуикс4real
На фото выше вы видите летопись многодневной, тяжелой и изнуряющей битвы пользователей с владельцем продукта (представители управляющей компании, наверное, удивились бы такому титулу и обиженно переспросили бы «НИМА УЧУН ШУНДАЙ КИЛЯПСАН?»).
Короче, дело было так:
1. Жила-была Даниловская мануфактура с удобной лестницей. Все пользовались лестницей и были счастливы.
2. Управляющая компания в рамках Федеральной программы «Задай огня этим пешеходам» поставила кладбищенскую оградку в конце лестницы, какбе намекнув людям ходить в обход по набережной без тротуара и c кучей машин.
3. Народ пожал плечами и стал перешагивать через оградку.
4. Управляющая компания, возомнив себя шашечным гроссмейстером, сделала свой ход, выдвинув на переднюю позицию клумбу, которая нафиг заблокировала лестницу.
5. Народ пожал плечами и стал топтать газон.
6. Итог: вытоптанный газон, кладбищенская оградка, клумба в конце лестницы, пожимающий плечами народ. Вид, деликатно скажем, уродливее некуда. Если бы это был сайт, то он попал бы к нам в БИСКВИТНЫЙ ДВОР и мы долго и обидно смеялись бы над его фасоном.
Мораль I: ставьте дверь там, где ходят люди, а не там, где возжелалось вашей экспертной заднице. Иначе люди пробьют двери сами.
Мораль II: если понять, по какой логике управляющие компании занимаются благоустройством, то откроется сакральное знание, как вообще существует сайт galya.ru.
#хуикс4real