Я аналитик, который пишет непонятные ТЗ. Т.е. я пытаюсь писать очень понятные ТЗ. В целом, я слушаю клиентов, потом я слушаю разработчиков, потом голоса в своей голове. Зачем я говорю с ними? В общем, получается то, что получается. Ну вы поняли.
Написать идеальное ТЗ проще простого:
1. Договорился о минимальном этапе (на 2-4 недели).
2. Описал юзер-стори по шагам.
3. Составил список экранов будущей системы.
4. Прописал названия методов API и форматы данных.
5. Запросил тестовый контент и составил таблицы с тестовыми данными.
6. Сформулировал из всего этого цели и задачи.
7. Согласовал план работ и выставил задачи в таск-менеджер.
Но не тут-то было! Давайте я расскажу, как все происходит в реальной жизни, а также поделюсь своими лайфхаками, как я с этим справляюсь.
Тот момент, когда у заказчика в кафе кончился словарный запас, и он прешел к изобразительному искусству. Так появляются карты наступательных операций по захвату мира прямо на салфетках. Не всегда везет присутствовать при этом лично, тогда в вотсапе сваливается фоточка салфетки в изометрической проекции в рубрику “без комментариев”.
Клиенту сложно сформулировать, что он задумал. Сложно продумать все возможные варианты работы системы, поэтому я часто прошу его рассказать о своей жизни и о том, как же он пришел к этим великим идеям. Обычно, после этого рассказа, как минимум, можно понять основные цели и задачи, ведь теперь мы знаем, из какой реальности к нам пришли эти демоны.
Открываем ТЗ и видим, что бы вы думали? Портал с виртуальным кладбищем:
* поднять захоронение в топ 100;
* поделиться захоронением с другом;
* отправить захоронение на главную;
* добавить в некрополь;
* добавить захоронение в черный список;
* активировать карту вип-пользователя;
* установить антивирус;
* кастинг;
* групповые склепы со знаменитостями.
Иногда заказчик настолько увлечен своими гениальными идеями, что не в силах признать нарушения в логике. Если вы напрямую укажите на логические противоречия, то клиент скажет, что никаких логических противоречий нет, а вы просто не слушаете о чем вам говорят, и делать будем именно так. Решено!
А всего-то, ему нужно услышать свои мысли немного другими словами:
— Правильно ли я понимаю, что вы хотите сделать кастинг захоронений?
— Правильно ли я понимаю, что пользователи будут выводить склепы в ТОП-100?
— Я правильно вас услышал, что пользователи будут приглашать друзей в братские могилы?
— Правильно ли я понимаю, что пользователи будут добавлять могилки в “черный список”?
— Правильно ли я понимаю, что знаменитости мечтают вписать в групповые склепы?
Т.е. вы не критикуете, не сопротивляетесь, не спорите, просто уточняете.
— Зарегистрируйся в нашей системе и стань известным и успешным.
— А что нужно делать, дальше?
— Ну вот ты зарегистрировался первый шаг уже сделан!
— ОК, а какой второй шаг?
— Ну активируй карту и подними свою анкету в топ-100.
Иии? Очень хочется услышать рецепт до конца!
Ха! Все было бы идеально, если бы заказчик вменяемо отвечал на заданные вопросы. Не спорю, многие отвечают, но есть и те, чьи ответы ничерта не проясняют. С ними нужно немного по-другому. Им нужно нарисовать сценарий в виде вопроса:
— А что, если пользователь зарегистрировался, активировал карту, поднял анкету, но не стал известным и успешным?
Денежка идет отсюда вот сюда, тут маленькая стрелочка, а тут процентики, сюда эти баллы, а туда эти баллы. Прямо железнодорожный вокзал на листке бумаги!
Когда я вижу что-то похожее на математику, но без контрольного примера, мне сразу становится страшно, ведь я хорошо себе представляю, что мне скажут разработчики до и в процессе разработки.
При этом просто попросить контрольный пример не получается. Если бы заказчик мог сделать контрольный пример, он бы его сделал и не занимался бы изобразительным искусством. Поэтому контрольный пример придется делать вам как минимум в “Экселе”. Не всегда хватает “Экселя” — возможно, потребуется MathLab или же полноценный исследовательский этап, если у вас внезапно нарисовался DSP, или 3D расчеты, или же распознавание образов с блэк-джеком и нейросетями.
Результатом этой работы должен быть набор тестов, который дает однозначные с точки зрения математики результаты.
— Хотим стримить порно через приложение в AppStore.
— Но нас же заблокируют!
— Не грузи меня деталями!
— Хотим стримить по wi-fi аквалангистов с кораллового рифа
— А wi-fi работает под водой?
— Не грузи меня деталями!
— Хотим раздавать 4G wi-fi с автономного роутера, но только тем, кто зарегистрировался в нашей базе.
— То есть придется колхозить прошивку для роутера и ехать в Китай?
— Не грузи меня деталями!
— Хотим подключиться к базе общественного транспорта Москвы
— А вы уже договорились с DIT?
— Не грузи меня деталями!
Перед нами стратег, у которого свой vision, и ничто не способно остановить его движение к успеху! Какие-то мелкие детали (законы физики, современные технологии, политики платформ) их не волнуют — это все только для технических специалистов.
Однако способ достучаться до “негрузидетальных” заказчиков есть — это нарратив. Они вполне смогут услышать историю, про то как:
* На AppStore недавно забанили вашего дружбана за порнушку.
* Мужик на YouTube пытался заняться зимней рыбалкой с wi-fi экшн камерой, чтобы посмотреть как рыба реагирует на наживку (черт, я ведь не шучу сейчас!).
* Как другой ваш дружбан колхозил прошивку для роутера, а в Гуанчжоу его киданул гид.
* Как вы уже полтора года ждете ответа от DIT Москвы.
Казалось бы, что это же частные случаи, и “у нас-то все будет по-другому!” Но, как не удивительно, заказчик-стратег верит байкам, особенно тем, которые травят их друзья. Отсюда вытекает другая проблема.
— Давайте спарсим выдачу “Яндекса”!
— ЧТОА? Эээ… Мммм… Как? Заачееем?
— Чтобы сэкономить на поисковом движке!
— Давайте для iPhone напишем три приложения которые будут внутри iPhone друг с другом взаимодействовать!
— Заааааачеееееем???
— Для повышенной безопасности: одно будет шифровать трафик, другое будет следить за обновлениями, а третье будет чатом.
Когда вас заставляют делать дичь, надо отказываться. Я так за всю практику ничего и не придумал, что с этим делать. Вилы в любом случае. Да, если вы отказываетесь делать Дичь, то иногда приходится увольняться, или отказываться от дохода. Но если вы соглашаетесь делать Дичь, то разрешаете превратить свою работу в ад.
Конечно, есть третий путь: можно уговорить заказчика пойти стандартным путем и сделать все правильно. Иногда мне это удается.
В целом, метод такой:
* Задать вопросы.
* Определить ценности и потребности.
* Предложить несколько альтернативных вариантов заказчику, о которых он не знал или не думал.
Дичь бывает разной степени упоротости. Если Дичь не слишком жесткая, то заказчик находит себе какую-то неопытную жертву, которая соглашается. Если Дичь чересчур, и все поголовно от нее отказываются, то заказчик прозревает, расстраивается и уходит бухать или, в самых тяжелых случаях, пробует сам учиться программированию, чтобы всем что-то доказать.
Сэйлз выцепил клиенток из Tinder’а.
— Здесь у нас будут видеотрансляции с девушками, здесь у нас будет чат, здесь мы будем взимать деньги за голосовые звонки девушкам. Во всех чатах, и в видео, и в голосовом, у нас будут фильтры, чтобы мужчины не обменялись с девушками телефонами напрямую. А то ж все такие хитрые!
— Отлично! А вы уверены, что такой фильтр существует?
Обычно, когда разработчики видят такое, то они цепляются за это мозгом и спорят с заказчиком. А нужно задать себе вопрос: “ОК, тут затык, а все остальное в этом проекте — идеально?”
Конечно же нет! Ведь причуды не ходят поодиночке. Выясняется, например, что: между соучередительницами не улажены юридические вопросы, они находятся в разных странах и ненавидят друг друга, какая-то несчастная команда уже начинала это пилить, теперь проект покоится на компакт-диске, который не читается, и нужно заняться полировкой царапин…
И тут вы сразу расслабляетесь, перестанете спорить и предлагаете заказчику вернуться к обсуждению после улаживания всех остальных вопросов.
Представьте себе миленькую международную компанию-гигантика. В ней ТЗ нужно согласовать со всеми департаментами. Нами предложены три варианта реализации. Ну, знаете, как в крупных компаниях говорят с подрядчиками? А вот так: “Предложите нам вариааанты!” (обязательно с оттяжечкой и “н” так в носик). Так вот, одним отделам понравился один вариант, вторым — второй, третьим — третий. И все так чатятся в режиме правки. Смогу ли я узнать ТЗ, которое получу на выходе после правок?
Чем больше проект, тем больше вариантов реализации, больше правок, больше технических рисков, логических несрастух и недосказанности. Поэтому я всегда стараюсь уговорить заказчика на минимальный этап с минимальным функционалом. Но не всегда так можно. Конечно же, все хотят строить космолет — это же гораздо престижнее! И начинать строить космолет с капитанской рубки — это же показатель профессионализма, ведь правда же!
У меня в почте есть 18-ая, а есть даже и 23-я версия ТЗ из 6-ти страничек. Все уже настолько задолбались, что никто уже не хочет сводить это все вместе… Нестерпимо хочется в производство!
Каков путь к идеальному понятному ТЗ? Он очень простой: никогда не начинайте работать, пока не получите хотя бы минимально информацию и материалы по всем пунктам для идеального ТЗ, которые я описал в начале. Но есть проблема: так вы никогда не начнете работать. Поэтому в реальности приходится изворачиваться по-всякому, применять лайфхаки, слушать угрозы клиентов, жалобы менеджеров и недовольство разработчиков. И Agile от этого всего не спасает, ох не спасает…
Написать идеальное ТЗ проще простого:
1. Договорился о минимальном этапе (на 2-4 недели).
2. Описал юзер-стори по шагам.
3. Составил список экранов будущей системы.
4. Прописал названия методов API и форматы данных.
5. Запросил тестовый контент и составил таблицы с тестовыми данными.
6. Сформулировал из всего этого цели и задачи.
7. Согласовал план работ и выставил задачи в таск-менеджер.
Но не тут-то было! Давайте я расскажу, как все происходит в реальной жизни, а также поделюсь своими лайфхаками, как я с этим справляюсь.
Скан салфетки (Что это мы нарисовали на встречке?)
Тот момент, когда у заказчика в кафе кончился словарный запас, и он прешел к изобразительному искусству. Так появляются карты наступательных операций по захвату мира прямо на салфетках. Не всегда везет присутствовать при этом лично, тогда в вотсапе сваливается фоточка салфетки в изометрической проекции в рубрику “без комментариев”.
Лайфхак: “Как ты к этому пришел, приятель?”
Клиенту сложно сформулировать, что он задумал. Сложно продумать все возможные варианты работы системы, поэтому я часто прошу его рассказать о своей жизни и о том, как же он пришел к этим великим идеям. Обычно, после этого рассказа, как минимум, можно понять основные цели и задачи, ведь теперь мы знаем, из какой реальности к нам пришли эти демоны.
Извращенная логика
Открываем ТЗ и видим, что бы вы думали? Портал с виртуальным кладбищем:
* поднять захоронение в топ 100;
* поделиться захоронением с другом;
* отправить захоронение на главную;
* добавить в некрополь;
* добавить захоронение в черный список;
* активировать карту вип-пользователя;
* установить антивирус;
* кастинг;
* групповые склепы со знаменитостями.
Лайфхак: “Правильно ли я вас понял?”
Иногда заказчик настолько увлечен своими гениальными идеями, что не в силах признать нарушения в логике. Если вы напрямую укажите на логические противоречия, то клиент скажет, что никаких логических противоречий нет, а вы просто не слушаете о чем вам говорят, и делать будем именно так. Решено!
А всего-то, ему нужно услышать свои мысли немного другими словами:
— Правильно ли я понимаю, что вы хотите сделать кастинг захоронений?
— Правильно ли я понимаю, что пользователи будут выводить склепы в ТОП-100?
— Я правильно вас услышал, что пользователи будут приглашать друзей в братские могилы?
— Правильно ли я понимаю, что пользователи будут добавлять могилки в “черный список”?
— Правильно ли я понимаю, что знаменитости мечтают вписать в групповые склепы?
Т.е. вы не критикуете, не сопротивляетесь, не спорите, просто уточняете.
Все и так понятно (прочитайте мои мысли)
— Зарегистрируйся в нашей системе и стань известным и успешным.
— А что нужно делать, дальше?
— Ну вот ты зарегистрировался первый шаг уже сделан!
— ОК, а какой второй шаг?
— Ну активируй карту и подними свою анкету в топ-100.
Иии? Очень хочется услышать рецепт до конца!
Лайфхак: “А что если?”
Ха! Все было бы идеально, если бы заказчик вменяемо отвечал на заданные вопросы. Не спорю, многие отвечают, но есть и те, чьи ответы ничерта не проясняют. С ними нужно немного по-другому. Им нужно нарисовать сценарий в виде вопроса:
— А что, если пользователь зарегистрировался, активировал карту, поднял анкету, но не стал известным и успешным?
Описание математики рисунком
Денежка идет отсюда вот сюда, тут маленькая стрелочка, а тут процентики, сюда эти баллы, а туда эти баллы. Прямо железнодорожный вокзал на листке бумаги!
Лайфхак: “А давайте посчитаем это в XLS”
Когда я вижу что-то похожее на математику, но без контрольного примера, мне сразу становится страшно, ведь я хорошо себе представляю, что мне скажут разработчики до и в процессе разработки.
При этом просто попросить контрольный пример не получается. Если бы заказчик мог сделать контрольный пример, он бы его сделал и не занимался бы изобразительным искусством. Поэтому контрольный пример придется делать вам как минимум в “Экселе”. Не всегда хватает “Экселя” — возможно, потребуется MathLab или же полноценный исследовательский этап, если у вас внезапно нарисовался DSP, или 3D расчеты, или же распознавание образов с блэк-джеком и нейросетями.
Результатом этой работы должен быть набор тестов, который дает однозначные с точки зрения математики результаты.
Не грузи меня деталями
— Хотим стримить порно через приложение в AppStore.
— Но нас же заблокируют!
— Не грузи меня деталями!
— Хотим стримить по wi-fi аквалангистов с кораллового рифа
— А wi-fi работает под водой?
— Не грузи меня деталями!
— Хотим раздавать 4G wi-fi с автономного роутера, но только тем, кто зарегистрировался в нашей базе.
— То есть придется колхозить прошивку для роутера и ехать в Китай?
— Не грузи меня деталями!
— Хотим подключиться к базе общественного транспорта Москвы
— А вы уже договорились с DIT?
— Не грузи меня деталями!
Лайфхак: “Был тут один случай!”
Перед нами стратег, у которого свой vision, и ничто не способно остановить его движение к успеху! Какие-то мелкие детали (законы физики, современные технологии, политики платформ) их не волнуют — это все только для технических специалистов.
Однако способ достучаться до “негрузидетальных” заказчиков есть — это нарратив. Они вполне смогут услышать историю, про то как:
* На AppStore недавно забанили вашего дружбана за порнушку.
* Мужик на YouTube пытался заняться зимней рыбалкой с wi-fi экшн камерой, чтобы посмотреть как рыба реагирует на наживку (черт, я ведь не шучу сейчас!).
* Как другой ваш дружбан колхозил прошивку для роутера, а в Гуанчжоу его киданул гид.
* Как вы уже полтора года ждете ответа от DIT Москвы.
Казалось бы, что это же частные случаи, и “у нас-то все будет по-другому!” Но, как не удивительно, заказчик-стратег верит байкам, особенно тем, которые травят их друзья. Отсюда вытекает другая проблема.
Д — Дичь! (так никто не делает)
— Давайте спарсим выдачу “Яндекса”!
— ЧТОА? Эээ… Мммм… Как? Заачееем?
— Чтобы сэкономить на поисковом движке!
— Давайте для iPhone напишем три приложения которые будут внутри iPhone друг с другом взаимодействовать!
— Заааааачеееееем???
— Для повышенной безопасности: одно будет шифровать трафик, другое будет следить за обновлениями, а третье будет чатом.
Лайфхак: “Без нас”
Когда вас заставляют делать дичь, надо отказываться. Я так за всю практику ничего и не придумал, что с этим делать. Вилы в любом случае. Да, если вы отказываетесь делать Дичь, то иногда приходится увольняться, или отказываться от дохода. Но если вы соглашаетесь делать Дичь, то разрешаете превратить свою работу в ад.
Конечно, есть третий путь: можно уговорить заказчика пойти стандартным путем и сделать все правильно. Иногда мне это удается.
В целом, метод такой:
* Задать вопросы.
* Определить ценности и потребности.
* Предложить несколько альтернативных вариантов заказчику, о которых он не знал или не думал.
Дичь бывает разной степени упоротости. Если Дичь не слишком жесткая, то заказчик находит себе какую-то неопытную жертву, которая соглашается. Если Дичь чересчур, и все поголовно от нее отказываются, то заказчик прозревает, расстраивается и уходит бухать или, в самых тяжелых случаях, пробует сам учиться программированию, чтобы всем что-то доказать.
С — Схема! (как хотелось бы, но не работает)
Сэйлз выцепил клиенток из Tinder’а.
— Здесь у нас будут видеотрансляции с девушками, здесь у нас будет чат, здесь мы будем взимать деньги за голосовые звонки девушкам. Во всех чатах, и в видео, и в голосовом, у нас будут фильтры, чтобы мужчины не обменялись с девушками телефонами напрямую. А то ж все такие хитрые!
— Отлично! А вы уверены, что такой фильтр существует?
Лайфхак: “А все остальное идеально?”
Обычно, когда разработчики видят такое, то они цепляются за это мозгом и спорят с заказчиком. А нужно задать себе вопрос: “ОК, тут затык, а все остальное в этом проекте — идеально?”
Конечно же нет! Ведь причуды не ходят поодиночке. Выясняется, например, что: между соучередительницами не улажены юридические вопросы, они находятся в разных странах и ненавидят друг друга, какая-то несчастная команда уже начинала это пилить, теперь проект покоится на компакт-диске, который не читается, и нужно заняться полировкой царапин…
И тут вы сразу расслабляетесь, перестанете спорить и предлагаете заказчику вернуться к обсуждению после улаживания всех остальных вопросов.
Коллективное творчество (правка в правке в режиме правки, “Ворд” — в лоскуты)
Представьте себе миленькую международную компанию-гигантика. В ней ТЗ нужно согласовать со всеми департаментами. Нами предложены три варианта реализации. Ну, знаете, как в крупных компаниях говорят с подрядчиками? А вот так: “Предложите нам вариааанты!” (обязательно с оттяжечкой и “н” так в носик). Так вот, одним отделам понравился один вариант, вторым — второй, третьим — третий. И все так чатятся в режиме правки. Смогу ли я узнать ТЗ, которое получу на выходе после правок?
Лайфхак: “Жрем слона по частям”
Чем больше проект, тем больше вариантов реализации, больше правок, больше технических рисков, логических несрастух и недосказанности. Поэтому я всегда стараюсь уговорить заказчика на минимальный этап с минимальным функционалом. Но не всегда так можно. Конечно же, все хотят строить космолет — это же гораздо престижнее! И начинать строить космолет с капитанской рубки — это же показатель профессионализма, ведь правда же!
У меня в почте есть 18-ая, а есть даже и 23-я версия ТЗ из 6-ти страничек. Все уже настолько задолбались, что никто уже не хочет сводить это все вместе… Нестерпимо хочется в производство!
Заключение
Каков путь к идеальному понятному ТЗ? Он очень простой: никогда не начинайте работать, пока не получите хотя бы минимально информацию и материалы по всем пунктам для идеального ТЗ, которые я описал в начале. Но есть проблема: так вы никогда не начнете работать. Поэтому в реальности приходится изворачиваться по-всякому, применять лайфхаки, слушать угрозы клиентов, жалобы менеджеров и недовольство разработчиков. И Agile от этого всего не спасает, ох не спасает…
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Поделиться с друзьями
dlinyj
Искусство коммуникации — очень важный параметр. В принципе главное адекватность заказчика. Иногда можно взять представить пилотную версиюю, что хочет заказчик и понять его адекватность. Логика, или нереальные задачи решаются пилотной версией. В принципе, как показывает практика — заказчик не будет ковыряться в конечном вашем решении. Можно согласиться, а потом сделать по своему.
Хотя был случай, когда в одном «ящике» людям предложили выкинуть из исходников ядра все неиспользуемые исходные коды драйверов. И весь отдел уволился (нереальная задача).
У меня был случай, когда мне за какие-то 50к предлагали отреверсить проткол обмена по CAN шине с сервером, с кучей датчиков, без документации и предоставления доступа к самой шине. При этом ещё и не факт что заплатят. Когда я намекнул, что это мягко скажем работа не на месяц и не за 50к, на меня очень сильно обиделись. Хотя изначально мне предлагалось всего лишь написать демон под железку за эту сумму.
Ну, а в целом, как по мне лучше чем в старом известном видео придумать нельзя.
krivotester
Спасибо за идеи!
В целом я давно вынашиваю план написать про переговоры в IT-проектах. Ну так чтобы с серьезной литературой, академические ученые (среди которых нобелевские лауреаты). Написать какие основные школы переговоров есть, какие плюсы минусы и т.п. -)
dlinyj
Проблема глобальнее. Исполнитель, как правило инженер, который на дух не переносит гуманитариев, и не очень читает всякие школы переговоров и прочее. И подход тут другой.
Задача научится понимать заказчика (самый тяжёлый случай, если он не инженер и даёт инженерную задачу) и исполнителя (инженера или программиста). В общем, переформулирую тезисно: неспециалист придумывает задачу и даёт специалисту, не представляя даже отдалённо проблем. Специалист должен не показать вида, что заказчик
конченный идиотгде-то ошибается и постараться выполнить данную задачу.Вот тут стоит искусство коммуникации. В ролике выше как раз показаны проблемы не работающего искусства коммуникации.
krivotester
Ну это прямо квест получается.
Запускаем разраба в комнату с заказчиком, и он должен:
— не выругаться
— не заржать
— угадать, что тот хотел
Если смог, то проходит в другую комнату, если заржал, ругается, время кончилось квест не пройден -)
dlinyj
Я выражаюсь, ругаюсь, смеюсь и остаюсь в комнате :). Что я делаю не так?
MooNDeaR
Выражаетесь, ругаетесь и смеетесь.
yurikgl
Разраба в одну комнату с Заказчиком можно запускать только если с той стороны тоже разраб и то под строгим контролем, что бы они не придумали космический корабль, не влезающий в бюджет )
mad_nazgul
В ролике 3 (ТРИ) человека, которые несут ответственность за коммуникации с заказчиком.
Но почему-то им нужен тех.специалист, который не умеет «коммуникацию».
Т.е. там 3 (ТРИ) человека не нужны, т.к. они не делают свою работу, и их можно безболезненно уволить. :-)
merlin-vrn
В ролике выше показаны отличия в понимании разными людьми одних и тех же слов.
Для одного параллельные — непременно непересекающиеся прямые, и перпендикулярность определена исключительно для прямых. Для другого — любые линии, которые всюду находятся на одном и том же расстоянии друг от друга («параллельные кривые»), а перпендикулярность определяется локально (в данной точке строим касательные к кривым и измеряем угол между ними, если 90° — кривые перпендикулярны).
Для одного прозрачный — это тот, который не видно, вообще не видно, а видно то, что находится за ним. Для другого прозрачный включает и «полупрозрачный» тоже.
Для одного котёнок — это объект трёхмерный, ну ладно, изображение может быть двумерным, но линия-то объект строго одномерный и не может быть в форме двумерного (про кривую Пеано он, предположим, не слышал). Для другого — линия — это как след от грифеля карандаша, вполне имеет осязаемую ширину, и можно сделать её любой формы, например, в форме котёнка.
И вывод: прежде, чем обсуждать, нужно договориться об определениях, и потом следовать им. Чтобы одни и те же слова понимать одинаково.
Вообще у этого «эксперта» какое-то ужасно узкое и закостенелое понимание мира. Дальше своих школьных знаний он ничего не приемлет. Наверное, на того, кто ему расскажет, будто можно определить операцию квадратного корня из отрицательных чисел, он тоже посмотрит как на идиота.
dlinyj
Этот ролик утрированный пример реальных дел. Я кучу раз был на подобных совещаниях. Меня всега тошнило от них.
QDeathNick
Не понимаю за что человеку столько минусов, хоть бы кто написал что не так.
merlin-vrn
Да ну их.
serg_p
Система минусов мне непонятна в принципе. По факту смесь голосования по теме изложения — но в привязке к личности выражавшей мнение, как то так.
si1v3r
Потому что он критикует пародию за нелогичность.
QDeathNick
Ясно, зря приучили людей к тегу /irony>
Germanets
«постараться выполнить данную задачу» — а после выполнения узнать, что заказчик хотел совершенно не это и не так? На мой взгляд это плохой вариант, который затягивает и сроки и добавляет кучу ненужной работы. Выполнять задачу пока она не понята одинаково обеими сторонами — точно непродуктивно, а вероятно что и некомпетентно, из серии — угадал-не угадал.
dlinyj
Мне кажется это отсылы к прошлым постам автора данного поста
EaE
Эксперт, за весь разговор ни разу не задавший вопроса «зачем».
krivotester
Я часто задаю этот вопрос, они бесятся с него -((((
Стараюсь отучаться.
Гораздо лучше вопрос: «Какие у вас ожидания», или «Допустим, все получится, опишите что тогда?»
Calc
Ну задавать «зачем» — бесит всех
Нужно по другому. Для чего вы это хотите? что вам это даст? Какая цель этого действа? Что в конце должно быть? и т.д.
Ответ должен быть не «я хочу котенка», а «я хочу продать это в майкрософт».
krivotester
Начальники и заказчики вырываются на верхушку пищевой цепи благодаря своей смелости.
Смелость часто подразумевает низкий уровень осознанности.
Это означает, что вопрос: «Что хочешь, что даст, какая цель, что в конце» ставит их в тупик! Да-да!
А вот что они ждут, или как они видят успех — обычно могут рассказать -))))
vanxant
Вы прям описали «слабоумие и отвагу»
krivotester
Вынужден признать, что недостаток слабоумия и отваги в организме, меня ограничивает -(
w4r_dr1v3r
Такие заказчики должны уничтожаться на подлёте к границам вашей студии.
8ajarz
ITMatika
Как вариант.
ITMatika
Также не могу не отметить, что первоисточник лучше экранизации: Совещание (профессионал).
Konachan700
А почему нельзя делать дичь, если она по силам и не абстрактна\невозможна? Хозяин-барин же, а кодер лишь исполнитель. Мне, например, с полгода назад прилетал заказ, как бы вы думали какой? Пройти техническое собеседование по скайпу вместо какого-то чувака. Ну хочет он попасть на работу в одну корпорацию на позицию java-миддла, однако навыков едва хватает даже на джуна, боится, что завалит на первом же вопросе. Я его честно предупредил, что так нельзя, он сказал, что знает что делает. А раз платит $150 за успех собеседования, то почему бы нет? Чел прошел, дальнейшей его судьбой не интересовался.
Calc
Ну это и не дичь.
Дичь это фильтр на видео по поиску лады баклажан за 2к рублей
Дичь — рекламные щиты в лифт за 5к рублей с полной разработкой сервера и т.д.
Дичь — сделать убийцу фейсбука
и т.д.
Konachan700
Можно впихнуть в этот бюджет при хорошем объеме. Себестоимость выходит в 3к рублей где-то при партии от 1к штук, картинку или видео забирает с ftp-сервера. Видел заказ этот кое-где, из интереса посчитал, поскольку есть возможность делать подобное. Но качество будет ниже плинтуса.
Или они хотели за 5к проектную документацию, чтобы потом самим делать? Тогда да, дичь…
Calc
Конечно проектная документация и всё всё всё.
Когда озвучиваешь ценник, ответ «а че так дорого?»
Calc
И да
Про партии в 1к штук вопросов нет, а так «с 3х домов начнем, там по 2 лифта»
krivotester
Если касается разработки, то заказчик в какой-то момент осознает дичь и все проблемы с нею связанные. При этом обвиняет в ней исполнителей, в зависимости от наглости клиента или начальника обвинения находятся в диапазоне от: «Я такого не предлагал» до «Да, это была моя идея, но вы как спецы должны были меня переубедить.»
Что интересно, даже собственноручно его сиятельством подписанные бумажки не действуют! Ответ может быть такой, например: «Я не осознавал, что подписываю, вы просто воспользовались моим непониманием тонкостей и получили утверждение при помощи хитрости!»
shornikov
Да, да. Такое случается и не в IT. Мой бывший шеф, бОООльшой олигарх, в ответ на показ ему бумажки с его подписью сказал «вы мне заставили».
w4r_dr1v3r
aquamakc
Есть ГОСТ 34.602-89. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Писал несколько ТЗ по нему. Получилось очень даже ничего.
А то, что автором приводится в начале темы — это не ТЗ, это заявление о намерениях, не имеющие с ТЗ ничего общего.
krivotester
Спасибо, что напомнили про ГОСТ.
У меня есть заказчики, которые кидают в меня ТЗ по ГОСТу, или детально документированным API на 200 страницах и просят разобраться и объяснить разрабам, а что делать собственно надо -)
aquamakc
Если ТЗ по ГОСТ, то адекватному разработчику ничего дополнительно объяснять не надо. Если надо — ТЗ таки запорото или у вас не разработчик, а кодер (оператор среды разработки).
aquamakc
Читал на днях книгу «Архитектура корпоративных приложений» за авторством Дино Эспозито. Очень многие моменты разработки архитектуры пересекаются с ТЗ по ГОСТ (пусть и называются по разному).
shuvaevgl
Был у меня случай, когда сеть мебельных магазинов захотела все же свести все звонки в единую сеть, а не как у них было: три городские линии, десяток сотовых и независимый call центр. Когда я сел с директором за один стол и попытался составить ТЗ или хотя бы нарисовать схему логики работы офисной АТС, я увидел печаль в глазах. Мне с десяток раз был задан вопрос: «Сколько это будет стоить?». На мои аргументы, что проект может быть оценен примерно только после составления ТЗ, был ответом еще более печальный взгляд.
Прошло более полугода и я до сих пор наблюдаю на известном сайте поиска работников вакансию сисадмина с глубоким знанием Asterisk за корок сопеек. А клиенты так и звонят то в call center, то на сотовый кладовщику, то на городской бухгалтеру…
krivotester
Ну т.е. попытка составить ТЗ привела к потере заказа?
shuvaevgl
На десятый вопрос о стоимости реализации я ответил: «от 100 до 500 тысяч, в зависимости от объема работ. Точнее скажем после утверждения ТЗ». На этом общение закончилось. Так что скорее жадность, раз они до сих пор ищут мальчика-все-в-одном
beskov
а чего вы им не сделали business case, который бы показал их текущие потери и обосновал бы ваши работы как вполне рентабельные?
shuvaevgl
Иногда дешевле не браться за определенную работу, чем потратить на доказательство того, что заказчику это нужно, свое время, которое тоже стоит денег.
beskov
ну так вы уже потратили значительно, судя по тому, что вам вопрос про деньги успели задать десять раз
может стоило после второго раза остановиться и накидать расчёты на салфетке?
shuvaevgl
3 часа набросков на 3 листах А4. Отдал схемы местному сисадмину, чтобы он с директором утвердил желаемые варианты работы (1-2 варианта переадресаций). После разговаривал с директором пару раз.
По итогу, директор хочет возложить создание АТС с распределенной сетью магазинов и call-центром на сисадмина с з.п. 30 тыс :)
KonstantinSoloviov
и тот это сделает за два года, что и будет стоить те же полляма :)))
krivotester
Но заказчика это все равно ничему не научит, и он продолжит жрать кактус в похожих кейсах -)
ClosedSneaky
«Я тебя полюбил, я тебя научу» © Уэф
Начинать надо с изучения сегмента рынка на котором
собираешься работать. Сбор информации, анализ.
Идти на встречу с заказчиком желательно после
синтеза собственного видения проблемной области.
В идеале — прототипировать пару-тройку экранов, еще лучше
это сделать совместно с дизайнером, чтобы глаз радовало.
Имея на руках презентацию и прототип легче перевести разговор с заказчиком
в конструктивное русло. На самом деле, рынки уже сложились.
Обзоры есть в продаже. Нормативная база также. Часть инфы гуглится.
Нарабатывать базу прототипов можно и заранее, не дожидаясь
звонков от клиентов. Добавлю, что автору удалось в статье очень логично
и талантливо в рамках своей собственной уникальной системы понятий описать процесс коммуникации
с клиентом, но к техническому заданию, как к регламентному документу
это не имеет отношения. Скорее протоколы, спецификации, психологические заметки,
но не ТЗ.
dlinyj
Перевод каретки использовали для удобности чтения?
peacemakerv
Тоже пытаюсь заставить заказчиков сформулировать ТЗ ну хоть как нибудь. Последнее время нравится идея писать ТЗ в виде нумерованного иерархического списка, где можно каждое слово верхнего уровня «разжевать» на нижнем уровне подробнее. Ну, вроде бы это просто — напиши идею в 5 словах. Потом ниже каждое слово опять распиши 5ю словами (ну, или меньше), и еще детальнее ниже, пока «детали не закончатся» на своём уровне мышления.
Даже сервис сделал совсем недавно на эту тему (androrder.xyz/h4w), но судя по статистике создаваемых проектов пользователями — идея им не очень нравится и составление ТЗ останавливается на 3-4 строчке.
krivotester
Вопрос формулирования ТЗ несколько глубже. Нужно взять на себя ответственность и напрячь мозг. Это не легко, люди этого избегают.
peacemakerv
Это вполне понятно, но надо же как-то сподвигнуть заказчика хоть что-то рассказать подробнее, особенно, если первичная тема запроса реально интересна. Вот и задача — как выудить инфо из заказчика не напрягая его. Чтобы как на допросе со спец средствами на вопросы ему отвечалось легко, без задержек…
krivotester
Ну вот я предлагаю рассказать о жизни.
Часто рассказ о жизни заказчика (чем он живет, кем работает, какое образование, как ему пришла эта идея, откуда, что он ждет от этого проекта) помогает в составлении правильного ТЗ лучше чем наличие ясных целей и задач.
Ведь они могут быть ложными, а история жизни обычно не врет -)
alexZzZzZzZ
У тебя на главной (https://androrder.xyz/) кодировка не указана. FF почему-то кирилицу ISO использует в этом случае, вместо utf-8.
peacemakerv
Спасибо, поправил.
Я вот думаю, может нужно разработать бота, задающего вопросы заказчику по какому-то алгоритму о свойствах\терминах проекта: откуда брать инфо, кто участник, какая его роль, и т.п.?
Nordicx86
ага Тз правда получаются жутковаты на вилд особенно когда видишь по 8-10 уровней иерархии, но жизннь облегчает радикально
w4r_dr1v3r
реализация им не нравится, а не идея. Идея-то как раз ничего.
reforms
Спасибо за статью, словно побывал на той стороне процесса.
Но вопрос один имеется: «ТЗ высокой четкости» для кого?
Я разработчик и бывало такое когда ТЗ утвердило руководство, акцептовал начальник отдела аналитики собрали все подписи с клиента, а потом удаленький разработчик задает маленький вопрос и все летит в там-тарары.
krivotester
ТЗ для взаимопонимания, а еще для понимания куда все движемся.
Идеально, когда с ним работают с обоих сторон, и удаленный разработчик в том числе -))))
reforms
Я имел в виду маленький (по должности), но удаленький, хотя согласен по контексту и удаленный тоже подходит
uniqm
Ребят, тут ведь все прозрачно. У клиента «проблема/желание». С нас выслушать его и «родить решение». А затем зафиксировать его в ТЗ. Я бы сразу разделил и не смешивал эти направления.
Когда клиент сам пытается родить именно решение — все упирается в его скилл. Как правило он никакой, оттуда и решения никакие (то розовую кнопку по центру экрана попросит, то еще что). Но это не отменяет наличия у него проблемы или потребности.
Если клиент пришел и говорит: «Хочу, что бы вы мне голову отрубили», то надо на автомате уточнить: «А исходя из чего Вы приняли такое решение? Какую жизненную задачу мы закроем? Какие еще решение рассматривали?» и т.д. т.п. Финансово частенько выгодно сказать: «Так точно! Будет сделано!», а потом на возражение клиента выдавать: «ВСЁ ПО ТЗ!». Но это не по «нашему» =)
Мне пока везет и клиенты с большим пониманием и доверием относятся к тому, что с них проблема/окружение/пожелания, а с меня поиск решения. Так не с первой встречи, но в процессе данный подход очевидно побеждает «Сделайте нам вот сюда вот именно вот так! Сколько стоит?» (если речь про долгосрочные отношения).
krivotester
1. Клиент далеко не всегда понимает свою проблему или желание, а иногда даже скрывает ее! Типа, чтобы было дешевле или по другим причинам.
2. Иногда кажется, что проблема или желание яснее ясного, все по полочкам разложено и записано, а потом оказывается, что что-то упустил.
3. Часто в ходе разработки проблема или желание меняются до неузнаваемости, но не всегда заказчик это осознает. Ему кажется, что всегда он хотел именно этого, просто вы не поняли.
4. Изменения проблем и желаний могут быть по массе причин: рынок изменился, осознание изменилось, компания изменилась, мода изменилось.
Так что вам ооочень сильно везет -)))) Очень!
Germanets
Ох уж этот замечательный третий пункт… вроде и делаешь всё как просили, и записываешь всё по буквам, а в итоге — сам дурак… Так иногда и хочется с диктофоном к некоторым товарищам приходить…
krivotester
А ходили знакомые с диктофоном — бесполезняк. Вот! Я же вам говорил, а вы меня не слушали, и не поняли! -)))
uniqm
1. Вот это зря. Бизнес прекрасно понимает, где у него жмет. Иначе бы не началось телодвижение. Да, сформулировано может быть как в старом анекдоте. Но аналитик должен докопаться до истины с приемлемыми затратами, ну работа такая.
2. В любых договоренностях так может быть, очевидно.
3 и 4. А никто и не говорит что требования в камне. Они живые. Один разок я полгода писал ТЗ для лаборатории, а как подписали все шишки, смена законодательства и ТЗ в утиль. Я не расстроился ;)
Везет мне как всем, вопрос в постановке задачи/роли аналитика ;)
krivotester
Это выдает в вас сторонника теории рационального поведения экономических субьектов.
Есть немало современных экономистов, в том числе нобелевские лауреаты, которые убедительно доказываеют иррациональность поведения экономических субьектов. На вскидку можно почитать: Роба Шиллера, Джозефа Стиглица, Дэна Канемана, Джо Аркелофа.
Короче, телодвижение может начаться не из-за прекрасного понимания. А просто вот так начаться иррациональненько -)
uniqm
Нет не выдает ^^ Условно половину обращений я закрываю, мол «нет проблем», «переложить на других», «в данных условиях/формулировках/требованиях не решаются», «решаются штатными средствами», «решаются организационно/юридически/другое».
Для меня обращение бизнеса — это входящая задача. Решением задачи может быть в итоге ТЗ. Именно может быть, а не обязано.
krivotester
Т.е. вы признаете, что бизнес генерирует часто рандомные задачи, а не те которые вызваны экономической целесообразностью?
uniqm
Именно об этом я и написал выше. Но это нормально. Что то из обращения пойдет в ТЗ на реализацию, что то «забреется». Не вижу проблем, оно так устроено и в других отраслях.
krivotester
Может забреется, а может и колом поперек горла встать. Даже если вы на зарплате, или на почасовом контракте может плохо кончиться.
KonstantinSoloviov
Я признаю! Мало того, могу дать простое тому объяснение.
«Бизнес» это не абстрактный конь в вакууме — это немножко другие, но все же люди обреченные доказывать свои высокие зарплаты своей часто сомнительной нужностью.
Инициатива проявлена? Суета создана? Что там технари что-то нарисовать не могут? А почему? Вот оно как… Ну не могут так не могут… ;)
Через так, получают дополнительную информацию, которую добывать сложно/долго/нудно/скучно/лень… И, на новый круг!
Для людей, которые любят и делают дело, бессмысленные совещания — помеха, для такого «бизнеса» — хлеб насущный.
krivotester
1. Объяснения лежат глубже, т.к. рациональных людей вообще не существует, что подтверждается массой воспроизводимых экспериментов.
2. «Коммуникация важнее документации» — это факт.
KonstantinSoloviov
>рациональных людей вообще не существует
Интересная мысль. Выстраданная или преобретенная? На переговорах попросил бы определить «рациональность» с Вашей кочки зрения. :)
>На вскидку можно почитать: Роба Шиллера, Джозефа Стиглица, Дэна Канемана, Джо Аркелофа.
Можно поконкретнее — две три книги из серии 'mast have'? С ответом не тороплю.
krivotester
Мысль прочитанная в книжках -)
По нобелевским лауреатам последних лет:
1. Шиллер «Иррациональный оптимизм» — там как инвесторы принимают решения
2. Стиглиц «Крутое пике» — о последствиях веры в «рациональность» рынков
3. Кругман «Выход из кризиса есть» — о том что можно сделать для экономики, поняв что экономические субъекты иррациональны
4. Шиллер и Аркелов «Spiritus Animalis» — как иррациональность правит экономикой
5. Канеман «Принятие решений в условиях неопределенности» — о том, как люди ошибаются в прогнозах и почему.
6. Канеман «Думай медленно, решай быстро» — название на русском абсолютно неправильное, но книга в продолжение темы принятия решений
И если хватит сил
Дэн Ариэли, думаю он тоже получит премию лет через 10:
1. Предсказуемая иррациональность
2. Позитивная иррациональность
3. Вся правда о неправде
KonstantinSoloviov
Спасибо
Alexeyco
Сформулировал из всего этого цели и задачи — на 6 месте? Почему не на первом?
krivotester
Потому, что не погрузившись в проблему цели и задачи сформулировать не удается!
Иногда формулирую их на 2-ом, 3-ем этапе.
Однако тестовый контент может все в корне поменять!
Alexeyco
Может мы говорим о разных вещах. Но цели и задачи — наипервейшая цель и задача при написании ТЗ. Это мое мнение. Вероятно, системные аналитики думают иначе.
krivotester
У аналитика есть заказчик.
Бывают уникальные заказчики, которые сразу в состоянии увидеть цели и задачи.
Они на то и уникальны, что встречаются редко.
Поэтому на практике цели и задачи формулируются в процессе, а не в начале.
Однако разработчик их видит в самом начале обычно -)
Alexeyco
Мы говорим о разных ситуациях. Я, например, говорю о ситуации, когда разработчик постоянно занят разработкой, не важно — одного продукта непрерывно, либо разных продуктов, но тоже в потоке. В такой ситуации чтобы сэкономить время, он вообще вникает в нюансы поставленной задачи ровно в тот момент, когда ее получает.
В этом случае он должен взять ТЗ, прочитать сначала цели и задачи. Далее он должен понять, что будет обслуживать данный функционал. К примеру, наша команда буквально в данный момент занята разработкой кастомной системы информационной поддержки. Есть несколько ролей, которыми может обладать пользователь. Причем совершенно вразнобой. Пользователи заходят, задают вопрос, дальше вопрос отправляется в путешествие — с помощью координатора. Эксперт получает вопрос и время пошло, он должен ответить на него. Ответив, отправляет вопрос назад координатору. Координатор решает, что делать дальше — отправить на доработку, либо отправить ответ сразу вопросившему. И так дальше. Плюс от вопроса эксперт может откреститься. Но это уже нюансы.
Так вот, казалось бы все просто. Но это «просто» наложилось на неспособность аналитика выдоить из заказчика сначала цели, затем описание жизненного цикла, а затем — в ложное направление разработки. Не потому, что кто-то идиот, а просто потому, что… ну потому, в общем. Недостатки конкретной организации процесса в локальном курятнике. Так вот, пришлось вмешаться и вникать в это все самолично. В результате, когда это «просто» было уже, наконец, разложено до мелочей, стало понятно, что придется все буквально уничтожать и стартовать с самого начала. Было потеряно драгоценное время, которое лично мне хочется тратить на конструктивные действия, а не на припирания и беготню.
Когда-то я тоже считал такие нюансы малозначительными. Но это было следствием недостатка опыта. Увеличение количества и сложности задач (я поменял работу) повлекло желание получать четко сформулированные цели и задачи. Т.к. выдержать текущую загрузку и сохранить темп, не сойдя с ума, можно только так. А ведь еще нужно планировать время на саморазвитие и профессиональный рост.
Упрек не в конкретно ваш адрес, а в адрес всего менеджерства. Из-за него мы делаем неверные шаги и тратим время на ерунду. Из-за него годные специалисты шлют к черту все и увольняются, что сильно ударяет по остающимся. И так дальше. Нам нужны профессионалы. Менеджер — чрезвычайно важная позиция. А у нас почему-то принято считать, что менеджерами становятся не найдя себе применения или не желая его искать.
Такие дела.
krivotester
Я понимаю о чем вы.
При этом не будем забывать про классический этап «исследование предметной области».
Как-то все его опускают и считают бесплатным. Типа исследование предметной области и погружение в проблематику для джуниоров, а мы то профессионалы!
В 1998 меня учили в институте исследовать предметную область.
В 2008 мне казалось, что я сразу могу круто сформулировать цели и задачи для чего угодно.
А сейчас в 2017 я понимаю, что идти по ложному направлению совершенно нормально, главное не заходить далеко и двигаться маленькими шагами.
mad_nazgul
Ну с моей колокольни проблема несколько в другом.
Обычно происходит так.
Есть проект. В начале «исследуют предметную область», «составляют требования» и т.д.
И типа пока код как-бы писать не надо, т.к. «мы исследуем».
Потом когда уже таки да все исследовали/изучили начинаю/ем писать код.
И тут ВНЕЗАПНО выясняется, все что исследовали/изучили ~80% можно просто выкинуть.
Т.к. увидев работающий прототип заказчик говорит, что здесь он думал другое, тут понял вот так.
А это вообще сделано не правильно, т.к. вы сделали как правильно (как написано в нормативных документах), а нам надо, как нужно (как мы в действительности работаем)
И происходит интерактивный процесс.
Прототип-> Уточнение->Прототип.
И так пока не закончатся деньги.
И это бы ничего, но обычно от 3 до 6 месяцев, как раз уходит на «исследования».
А потом за 3-4 месяца нужно сделать продукт.
Поэтому я за Agile. Т.е. заказчик должен как можно раньше увидеть прототип, чтобы он мог на что-то опереться и высказать, свое «фи».
krivotester
Я работаю и так и эдак.
В целом стараюсь договориться на стартовый этап недели на две как раз, чтобы увидеть прототип как можно скорее.
— по ТЗ работаю
— по Agile работаю
Разница стирается, если ТЗ маленькое и уменьшается в мини-спринт.
При этом все-таки вы поднимаете вопрос прогнозирования.
Допустим все по Agile, двигаемся мини-задачами, которые сразу подходят для внедрения.
Однако внедрение на стороне клиента не происходит с той скоростью, которую вы ожидали.
Сотрудники раскачиваются медленно.
И когда через 3-6 месяцев часть народа удается на систему пересадить, выясняется что был изначально выбран ложный путь. Причем понимание этого нарастает лавинообразно. Вот не было его и вдруг появилось, как мода или как кризис среднего возраста-)
Alexeyco
И это я еще не затронул такие ситуации, когда вместо нормализации потребностей заказчика и приведения их в адекватное состояние менеджер стремится просто выполнить их без поиска компромисса. Тогда реализация всего превращается сначала в создание того, как надо, а потом в закостыливание этой красоты, чтобы она соответствовала глупостям. Примеров куча.
lingvo
Я разрабатываю аппаратно-программные платформы для управления силовой электроникой. В последнее время полюбил Jira, как средство для управления требованиями.
Т.е. каждое требование — это Issue. В описание обязательно должна быть прописана причина возникновения требования. Далее комментами выясняется и дополняется между всеми командами. В конце идет workflow по формальному review и approval.
Медленно, но верно. На основании требований создаются user stories и задания — каждое требование должно приводить к одному или более заданиям и каждое задание должно закрывать как минимум одно или несколько требований. Так появляется полная traceability от требований до svn.
krivotester
Супер, хороший путь.
А что заказчик по жире говорит?
lingvo
По жире ничего, так как основная нагрузка на мне — как менеджере управления требованиями — правильно сформулировать, разбить одно большое требование на несколько мелких, связать вместе, направить нужному спецу для комментов и т.д.
Как правило со стороны заказчика сидят несколько специалистов, которые только комментируют и утверждают требования. Поэтому нагрузка на каждого не такая большая и им собственно пофиг — то ли жира это, или что-то другое.
Самый неприятный вопрос к заказчику, как уже обсуждали выше — это "Зачем?". Вытягивать приходится за уши, граблями. И тогда вылазят такие интересные вещи, что жира постепенно превращается в кладезь мудрости.
krivotester
На «Зачем?» могут ответить что-нибудь в духе, а почему вы спрашиваете? Или каким боком ответ на этот вопрос влияет на работу?
merlin-vrn
Да, влияет. Мы скорее всего ваше объяснение поняли неправильно, и если мы будем делать так, вы заплатите лишние деньги за переделывание, но если вы объясните, зачем это вам нужно, понять вас правильно будет гораздо проще и максимально вероятно, что мы сделаем сразу именно так, как вы имели ввиду.
lingvo
От меня заказчикам так легко не уйти. Мы как бы под одной крышей. По теории каждое требование — это желание, потребность. А потребность возникает по какой-то причине. Если причины нет, то и потребность не возникнет. Следовательно ответ на вопрос "Зачем" позволяет лучше определить причины возникновения требования и в конце концов выяснить, насколько оно важно заказчику.
Часто в процессе выяснения "зачем" требование меняется до неузнаваемости.
Например в процессе обсуждения одного из самого простых требований: "Устройство должно работать в диапазоне температур от -25°C до +55°C" выяснилось, что:
И так далее. В результате это очень сильно влияет на выбор решения, даже если требование в результате не изменяется.
Alexeyco
Низкий поклон таким менеджерам. Ибо вас меньшинство. А большинство видят себя в некоей прослойке. Выслушать заказчика — передать разработчику. Но в процессе передачи «хочу» превращается еще и в «надо» без возможности внести малейшие коррективы в это «хочу». Выливается все в увеличение трудозатрат, либо в генерацию костылей. Результат — кривые, внутренне несогласованные программные продукты, которые разрабатывать просто пытка. А уж поддерживать…
akubintsev
Смеялся от души, жизненно!
Из недавнего прошлого. Средней величины компания, хочет новый лендинг. Пытаюсь набросать бриф. В каждой итерации постоянно появляются всё новые и новые крупные фичи. При этом всё время звучит один и тот же вопрос «а сколько всё это будет стоить». На что я постоянно отвечаю «давайте сперва определимся, что вы хотите в виде ТЗ».
На 3-4 итерации меня спросили «а у вас есть рыба ТЗ или может откуда-то это можно скачать?», на что я сидел с выражением «рука-лицо» и ответил сухо «такого не может быть в принципе» и, понимая неизбежность нечеловеческих затрат времени на детализацию ТЗ, посоветовал им нанять аналитика, если у них нет квалифицированного человека, готового ответственно отнестись к проектированию.
Тем не менее, через месяц мне прислали содранное откуда-то замшелое ТЗ со своими правками, в которых всё равно ничего не было написано про те фичи, о которых мне рассказывали ранее. Зато было пожелание поддерживать IE 5.0, Firefox 1.0, Chrome 5.0 и какой-то набор диких разрешений мобильных устройств и адаптивную верстку, при этом имея только один макет дизайна под 1280px.
На это мне ничего не оставалось сделать, как назвать с потолка сумму денег, окупившую бы весь гемор по этому ТЗ и серию вопросов «я правильно понял, что вы хотите то-то и то-то?». Там ошалели от стоимости. И конечно же оказалось, что мало чего нужно было, но дополнительной инфы так и не предоставили.
Как итог, я написал от всего сердца, что далее есть только одна возможность общения со мной на тему ТЗ — платить деньги за его составление. Либо не общаться со мной, а заплатить их аналитику, как делают все нормальные люди. В противном случае не смогу считать себя профессионалом, за результат и претензии не отвечаю, но деньги возьму вперед. Больше ответов пока не последовало.
Ах да. Вся это котовасия длилась полгода.
krivotester
Классика жанра -)
Но это вы еще не стартанули. У меня есть кейсы, где пол года согласовывали ТЗ и стартанули.
Вот тогда начинается самая мякатка -)
akubintsev
У меня пока мало опыта в таких делах, но что-то неладное почуял и решил, что лучше пусть уйдут, чем потом мне будут трахать мозг еще неизвестно сколько.
Больше всего умилило во всём этом не столько отсутствие понимания того, что хотят, сколько ощущение, что никому на самом деле этот проект не нужен, если учесть постоянные попытки спихнуть на меня написание ТЗ и отстраненность от этого процесса.
vanxant
Ну блин, слушайте же вашего заказчика.
Если заказчик просит не ТЗ, а смету, то ему и нужно предоставить смету.
Это такая табличка с укрупнёнными фичами. Такая-то фича будет стоить столько-то и займёт столько-то времени, а следующая — столько-то и столько-то. С пояснением «в стандартной комплектации».
Дальше, если фича реально нужна, начинается обсуждение «стандартной комплектации». Это уже подфичи.
Ну я понимаю, что если вы конкретно ту или иную фичу никогда не делали, то и оценить её сходу, а тем более аргументированно перечислить её «стандартную комплектацию», достаточно сложно. А если вообще не представляете, как это сделать — невозможно. Ну тут извините, аналитика кормит опыт, которого вам не хватило.
akubintsev
Я его и слушал. Беда в том, что заказчик говорит что-то, что сам не понимает. Допустим «хотим АВ-тесты». Ок, раскройте тему. Что именно тестируем, как, какие метрики собираем. Опа, по ходу надо писать уже не совсем лендинг, а систему сбора статы, поскольку желаемое GA/ЯМ не предоставляют? Давайте конкретнее тогда опишем метрики. Вместо этого меня спрашивают сколько будет весь проект. Пардон, но мы только копнули, кусочек верхушки айсберга. И таких моментов дофига и больше.
Возникало ощущение, что заказчик как попугайчик выучил какие-то умные слова, но что это такое не понимает и хотел, чтобы я сам всё додумал)
krivotester
Эмм ну я вот только вчера участвовал в отправлении сметы заказчику, который настаивал на том, что не хочет писать ТЗ, дайте смету!
Теперь он придирается к каждому пункту сметы: «а я не понимаю, почему эта фича займет у вас 6 часов, да это же 1,5 минуты»! -)))
Вот мы и думаем теперь, какие трудозатраты потребуются, чтобы с этим заказчиком спорить за каждый час в смете?
В целом отказ от ТЗ — уже симптом, который заставляет задуматься: а оно вам надо?
Gryphon88
Читал статью, а в голове упорно крутилось:
Лефортовский кондитерский комбинат. Спокойный среди бурь.
Fierta
Извращенная логика — Искривленный мозг ))
prostovovan
ТЗ — это рамки, устанавливаемые исполнителем для свой защиты. Начинать переговоры с защиты своих позиций — заведомо проигрышная тактика.
krivotester
Не припомню заказчиков, которым бы без ТЗ было счастье.
ТЗ гарантирует заказчику в некотором роде исполнимость проекта, хотя это не очевидно, но я могу это обосновать.
Bsplesk
Всем хорошего дня.
[с точки зрения заказчика от малого бизнеса]
Не нужна мне никакая гарантия «в некотором роде исполнимость проекта», ибо не ГосПопил с гостами = кривой калькой ISO и дополненный сборной солянкой = аналог дом который сдали но не подключили к коммуникациям, и возможно и не подключат, а с большей вероятностью снесут со временем.
Есть «кейс»(case) его нужно решить, уже посчитал сколько он может мне принести, и какую сумму могу на него выделить + ограничение по времени на реализацию + в уме дополнительную сумму на возможные изменения и соответственно риск провала.
Это ответ на вопрос «зачем», сами подумайте, зачем заказчику — деньги? Вася, а тебе зачем деньги?
С моей точки зрения «разработчик», это мой партнер по бизнесу, если он мне тыкает ТЗ = отказ от ответственности = «признание, что проект он ни осилит, и заранее делает — больше бумаги чище ....», с таким типом договора, забываем про этого «партнёра».
От нормального «разработчика» жду «бизнес/системного/аналитика/архитектора» — без вопроса зачем мне деньги. Составляется «скелет требований» в последствии выльется в дорожную карту — для меня, для контроля «разработчика» и возможности вылечить болезнь на ранней стадии возможно путем ампутации «разработчика» = уменьшить убыток.
Да «разработчику» это не понравится, да будут споры, так как требования не «прибитые гвоздями» — они живые и меняются, и все эти вопросы нужно заранее оговаривать, чтобы вписаться в «сумму» и «время», для этого постоянный контроль, обсуждения — на каких-то этапах возможно придется каждый день дискутировать, с обеих сторон, иначе риски не оценить.
На данном этапе от меня только бизнес.
Суть всех этих требований, чтобы заказчик понял «что мне требуется, за какое время и сколько ему на это нужно ресурсов».
Большое значение имеет доверие, как бы это не смешно не звучало, иногда проще начинать с решения простых кейсов, и смотреть, что из этого выходит, подходит ли тебе такой «партнер» или нет.
С точки зрения «разработчика», нужно определится с каким типом клиента он хочет работать.
Ибо купить килограмм яблок не равно вырастить килограмм.
krivotester
Правильно ли я вас понял, что:
1. Вы хотите знать какое потребуется время и сколько нужно ресурсов на то, что никак не сформулировано?
2. Вы хотите иметь ответственного партнера, которого при этом легко «ампутировать»?
Fierta
Тех. задание — это тех. задание, а отказ от ответственности — это отказ от ответственности. Они не равны, не взаимозаменяемы, это не одно и тоже…
Подобные умозаключения не логичны. Ошибочны. Как следствие, остальные выводы ошибочны. Продолжать читать дальше этой строки, не имеет смысла…
Bsplesk
krivotester
Правильно ли я вас понял, что:Это контроль процесса, выполнения моего кейса(case) разработчиком за мои деньги.
С моей точки зрения, процесс разбит на части «part», они указаны в дорожной карте согласованной с разработчиком.
За выполненную часть — оплата, у каждой части срок (deadline), в случае просрочки, подробный разбор полетов («митинг»), возможно у меня появились дополнительные требования, или наоборот разработчик при бизнес анализе «рассказал как он быстро строит горы», а на первом deadline понятно, что в его силах построить песочный замок за весь отведенный срок.
Причем просрочку будет уже видно до срока (deadline), есть время подготовится, и подумать обеим сторонам, что идет не так, а стоит ли вообще продолжать, что поправить, для достижения цели — это постоянный спор, здесь по возможности требуется приходить к взаимовыгодному решению.
При таком подходе, возможно грубое планирование экономической целесообразности, не редки ситуации когда к 1-2 deadline (две недели месяц), становится понятно, что при данным темпе и упёртости разработчика это убыточный проект, тут и принимается решение резать или не резать, за выполненный deadline разработчик свою часть оплаты получит, с моей стороны это плата за риск.
1) Мне интересно только время — скорость выполнения моих требований, но время под моим постоянным контролем, ресурсы это проблема разработчика.
2) Верно, Ничего личного, это просто бизнес. Без обмана, в самом начале об это обговаривается, как показывает практика, это «холодный душ» для разработчика.
krivotester
Получается, что вы работаете с разработчиками только когда они у вас «под постоянным контролем» и платите им почасовую?
Bsplesk
Постоянный контроль над выполнением моего кейса(case), косвенный образом тянет контроль расходов — с точки зрения бизнеса это один из бизнес процессов.
Как работает «разработчик» мне интересно*(см. ниже почему), главное, конечно, интересен результат их работы.
«Разработчик» получает фиксированную оплату (fix price) за выполненную часть (part) + сверху плюшку за добавленные/измененные требования с моей стороны, максимальная сумма на part определена заранее* — что несколько остужает «разработчика», за декомпозицию требований он не получает ничего, за спорные — спор, за выполнение нескольких part в срок получает плюшку.
«Разработчик» — образно, может быть компания, может быть команда, НО процесс должен быть «сквозным», от бизнеса, доступ ко всей команде, это важно при реализации требований, менеджер, конечно, остается, но не более одной «прокладки», в качестве «системы доступа», по ранее обговоренным требованиям, доступ на прямую к разработчику весь рабочий день, иначе получится испорченный телефон.
Это очень не любит руководство «разработчиков» — компаний, т.к. в данном случае, часто «плюшки» получает только руководство(мне до этого особо нет дела — пусть мотивируют, как умеют).
Но по практике, выходит так, что как казалось бы выделенный разработчик совершенной не мотивирован, занимается параллельно 2-3-5 заказчиками, категорически против этого метода — меня, как заказчика это не устраивает, сделал дело занимайся следующим, ибо когда сроки проср
Аочивается, а менеджер в спор, вот тут вопрос подумать, да и вообще эти вопросы требуется обговаривать за ранее, если договорились, что работаем напрямую с командой, то это должна быть команда, а не 0.011 мифических человека часа — до которых мне дела нет, если человек нужен только на n-part то это обговаривается заранее, с моей точки зрения — бизнеса, доступность команды, определяется доступностью, каждого её члена, если кто-то недоступен, то недоступна вся команда. Понятно, что кто-то может заболеть/уволится, но эта не моя проблема, должна быть оперативная, равнозначная подмена.* здесь постоянный спор, и возможно от части не критичных требований мне придется отказаться, по критичным возможно придем к взаимопониманию = договоренности, что это стоит больше.
pavia
Это же прекрасная иллюстрация требований заказчика неадеквата! Спасибо за яркий пример.
krivotester
У меня только один вопрос. Как вы сами считаете, применима ли ваша идеология в строительстве загородного дома, или при ремонте квартиры? И кто в этом случае несет расходы за материалы?
Donny
Т.е. вы хотите, чтобы компания-разработчик создала вам бизнес, взяла на себя все риски и отдала вам свой бизнес на блюдечке с голубой каемочкой?
Есть два пути: 1) идти на Freelance и самостоятельно нести там все риски того, что у вас возьмут предоплату и киданут или задолбаются от вас жёстко и пошлют подальше; 2) обращаться в компанию и смириться с тем, что она работает по бизнес-логике, и бегать за вами там никто не будет, и да, разработчики там работают профессионально, по ТЗ, по часам и с 5 и более заказчиками. Хотите индивидуальной работы? Отлично! Оплачиваете отдельную штатную единицу по часам с повышенной ставкой. И, конечно, никто вам никогда не даст возможности трахать мозги квалифицированному персоналу.
kuznetsovin
Мне вот интересно с вами работает, кто-то на таких условиях? Звучит очень странно просто, что нет требований, но есть сумма, и она фиксирована, а требования нет. На качество работ, тогда сразу забить можно.
w4r_dr1v3r
У меня два вопроса:
Заранее спасибо.
Bsplesk
Здравствуйте w4r_dr1v3r
Не работаю по ТЗ(ГОСТ 19.201-78, ГОСТ 34.602-89) --> «калька» IEEE 830 в оригинале можно посмотреть эволюции на сайте ISO, тег SRS.
Имею личное мнение и опыт, что методы применяемые для оценки и планирования объёма выполненной работы условного «каменщика», совершенно не применимы для оценки работы художника или компози?тора. И введение 100/500 стандартизованных пунктов качества ничем не помогут, если только не заказывается стандартная, шаблонная(template) вещь, типа сообщения закодированной при помощи азбуки морзе, да и то есть, большой шанс не найти взаимопонимания.
wishnewski
Вы путаете эмоциональные впечатления от процесса обсуждения с желанием разработчиков сэкономить всем время, тем самым позволив заработать всем больше денег. Какой же из вас предприниматель, если вы этого не понимаете?
В какой версии продукта код становится окончательным?
Её красота мешала вам отвечать на вопрос? ;)
Те московские разработчики пытались с вами по-человечески разговаривать, насколько я могу судить, не обращая внимания на ваш феерический клубок последствий отключения всех систем головного мозга, за исключением лимбической (сужу по вашему стилю изложения — не обижайтесь, вы в этом не одиноки — за пределы изобретения Гутенберга ещё многие люди на планете не выбрались).
Вам же стоит «немного» больше думать
о других людях.Donny
Ну, для композиторов у нас отдельный тариф — «Почасовой с двойной тарификацией за споры», и все довольны )
vanxant
Открою вам пару страшных тайн из реальной жизни.
1. Заказная разработка — это тоже бизнес. Ну совсем грубо говоря, владелец такой конторы покупает время у своих сотрудников и продаёт его вам, с налогами и прибылью. Если он ошибся при оценке стоимости разработки, он покупает больше времени, но продаёт его вам за тот же фиксированный прайс. Таким образом, оплачивая лишние часы разработчиков из своего кармана.
2. Соответственно, предложенная вами схема без ТЗ, без четких требований к продукту, но с фиксированными сроками и ценой, проканает только с совсем неопытными фрилансерами. Каждый юный предприниматель один-два раза накалывается на проектах с отсутствием ТЗ и всё, резко перестаёт быть волшебником в голубом вертолёте.
3. Рынок качественной разработки — это рынок продавца. Нравится вам или нет. В любой грамотной конторе огромная куча входящих заявок сразу идёт в корзину, если заказчик выглядит, просто выглядит, неадкватом. Либо же, если у заказчика явно есть деньги, в смету закладываются трёхкратные риски и огромный бонус «за вредность». Так что вам придётся либо играть по правилам исполнителя, либо очень сильно переплачивать.
4. Чем дальше вы продвинулись по этапам разработки, тем больше вы влипли. Исполнитель свои деньги ну плюс-минус получил, пусть и без прибыли, а у вас пока на руках лишь частично готовый продукт, использовать который нельзя. Если вас осенит гениальная идея, или если в ТЗ обнаружится ошибка — не важно, по чьей вине, или по какой-то ещё причине вы решите поменять ТЗ или выдвинуть новые требования — вам вежливо улыбнуться, выдвинут смету на доп. работы и пригласят в кассу. Не нравится? До свидания.
5. Доделывать проект в другой компании будет кратно дороже — ну, потому что новым разработчикам нужно время, чтобы въехать в тематику. Не потому, что разработчики такие злые или жадные, просто см. п. 1.
5. Однако, многие владельцы компаний друг с другом знакомы хотя бы через третьи руки, и не обломаются позвонить бывшему исполнителю узнать вашу характеристику, если вы к ним придёте «дорабатываться». Если вы вели себя как м… к, с вами просто никто не будет разговаривать.
peacemakerv
Ай, отлично сказано, спасибо. Разрешите утащить на цитаты?
vanxant
yr welcome
krivotester
Со всем согласен, при этом хочу обратить внимание на важную особенность, которую вы не учли.
Такие пассажиры далеко не всегда на первых встречах выглядят неадекватами или жесткими бизнесменами с яйцами (если орел я выиграл, а если решка ты проиграл).
На первых встречах они могут быть такие улыбчивые, позитивные, отзывчивые. Что-нибудь в духе:
— Да, я вас не обижу
— Да, от меня будет постоянный поток заказов
— Да, я всегда на стороне исполнителя
— Да, я ищу себе надежного партнера для долгосрочного сотрудничества
— Да, я не против ТЗ, просто пока толком непонятно и нужно нащупать рынок вместе с моим новым прекрасным партнером!
А если он еще и по знакомству пришел (а они любят прийти по знакомству), то эта конфетно-карамельная история бывает уносит в ванильные дали не только бывалых фрилансеров, но и опытных менеджеров и директоров малых и средних компаний, а бывает и крупных -)
vanxant
Ну не знаю, на опытных людей сказки про долгосрочное сотрудничество и кучу будущих проектов действуют обычно слабо. Будет — хорошо, не будет — ну и ладно. Есть конкретный проект, есть деньги по нему — вот над этим сейчас и работаем. А там будет видно.
yurikgl
Добавлю к этому, что вам скажут еще и сроки, которые могут быть весьма далекие т.к. команда, которая занималась вашим проектом должна перейти на другой проект, по которому уже оплачен аванс. Иными словами, в ряде случаев серьезные переработки в короткие сроки иногда сделать не получится даже за большие деньги т.к. у разработчиков другие планы.
peacemakerv
Я давно уже сделал на сайте форму для заказчиков, которых прошу её заполнить.
Один из пунктов — «Подходящий вариант оплаты», с вариантами:
Разумеется, подавляющее большинство заказчиков выбирает второй пункт с фикс. суммой за проект.
Так вот если они выбирают его, но отлынивают от составления ТЗ в файле — я сразу им напоминаю об этом несоответсвии, и 95% «пропадают в дали», переставая тратить моё время. Но малая толика «адекватов» все-таки остается, и обычно это наиболее серьезные и платежеспособные заказчики.
И так же достаточно заказчиков осознанно выбирающих последний пункт. И если работа с ними начинается — им уже даже приятно делать скидки и округления сумм вниз.
spmbt
Заказчик с виртуальным кладбищем — приходил ко мне (встречались в кафе) очень давно один такой, более 5 лет назад. Правда, кладбище не людей, а животных. Он тогда ещё NDA захотел подписать на 5 лет на неразглашение идеи и говорил, что собрал уже пачку таких обязательств. Потом оказалось, что денег очень мало и даже снять офис затруднительно, т.к. дорогой интернет там будет, и т.д.… Потом ещё долго видел его объявление на фрилансерах. Может, это тот же с тех лет ходит?: )
krivotester
Не наш -)
Это было очень много лет назад, и там были люди, а не звери, и с офисом и деньгами проблем точно не было -)
NDA тоже не было, проект публичный.