Comments 134
Искусство коммуникации — очень важный параметр. В принципе главное адекватность заказчика. Иногда можно взять представить пилотную версиюю, что хочет заказчик и понять его адекватность. Логика, или нереальные задачи решаются пилотной версией. В принципе, как показывает практика — заказчик не будет ковыряться в конечном вашем решении. Можно согласиться, а потом сделать по своему.
Хотя был случай, когда в одном «ящике» людям предложили выкинуть из исходников ядра все неиспользуемые исходные коды драйверов. И весь отдел уволился (нереальная задача).
У меня был случай, когда мне за какие-то 50к предлагали отреверсить проткол обмена по CAN шине с сервером, с кучей датчиков, без документации и предоставления доступа к самой шине. При этом ещё и не факт что заплатят. Когда я намекнул, что это мягко скажем работа не на месяц и не за 50к, на меня очень сильно обиделись. Хотя изначально мне предлагалось всего лишь написать демон под железку за эту сумму.
Ну, а в целом, как по мне лучше чем в старом известном видео придумать нельзя.
Хотя был случай, когда в одном «ящике» людям предложили выкинуть из исходников ядра все неиспользуемые исходные коды драйверов. И весь отдел уволился (нереальная задача).
У меня был случай, когда мне за какие-то 50к предлагали отреверсить проткол обмена по CAN шине с сервером, с кучей датчиков, без документации и предоставления доступа к самой шине. При этом ещё и не факт что заплатят. Когда я намекнул, что это мягко скажем работа не на месяц и не за 50к, на меня очень сильно обиделись. Хотя изначально мне предлагалось всего лишь написать демон под железку за эту сумму.
Ну, а в целом, как по мне лучше чем в старом известном видео придумать нельзя.
Спасибо за идеи!
В целом я давно вынашиваю план написать про переговоры в IT-проектах. Ну так чтобы с серьезной литературой, академические ученые (среди которых нобелевские лауреаты). Написать какие основные школы переговоров есть, какие плюсы минусы и т.п. -)
В целом я давно вынашиваю план написать про переговоры в IT-проектах. Ну так чтобы с серьезной литературой, академические ученые (среди которых нобелевские лауреаты). Написать какие основные школы переговоров есть, какие плюсы минусы и т.п. -)
Проблема глобальнее. Исполнитель, как правило инженер, который на дух не переносит гуманитариев, и не очень читает всякие школы переговоров и прочее. И подход тут другой.
Задача научится понимать заказчика (самый тяжёлый случай, если он не инженер и даёт инженерную задачу) и исполнителя (инженера или программиста). В общем, переформулирую тезисно: неспециалист придумывает задачу и даёт специалисту, не представляя даже отдалённо проблем. Специалист должен не показать вида, что заказчикконченный идиот где-то ошибается и постараться выполнить данную задачу.
Вот тут стоит искусство коммуникации. В ролике выше как раз показаны проблемы не работающего искусства коммуникации.
Задача научится понимать заказчика (самый тяжёлый случай, если он не инженер и даёт инженерную задачу) и исполнителя (инженера или программиста). В общем, переформулирую тезисно: неспециалист придумывает задачу и даёт специалисту, не представляя даже отдалённо проблем. Специалист должен не показать вида, что заказчик
Вот тут стоит искусство коммуникации. В ролике выше как раз показаны проблемы не работающего искусства коммуникации.
Ну это прямо квест получается.
Запускаем разраба в комнату с заказчиком, и он должен:
— не выругаться
— не заржать
— угадать, что тот хотел
Если смог, то проходит в другую комнату, если заржал, ругается, время кончилось квест не пройден -)
Запускаем разраба в комнату с заказчиком, и он должен:
— не выругаться
— не заржать
— угадать, что тот хотел
Если смог, то проходит в другую комнату, если заржал, ругается, время кончилось квест не пройден -)
В ролике 3 (ТРИ) человека, которые несут ответственность за коммуникации с заказчиком.
Но почему-то им нужен тех.специалист, который не умеет «коммуникацию».
Т.е. там 3 (ТРИ) человека не нужны, т.к. они не делают свою работу, и их можно безболезненно уволить. :-)
Но почему-то им нужен тех.специалист, который не умеет «коммуникацию».
Т.е. там 3 (ТРИ) человека не нужны, т.к. они не делают свою работу, и их можно безболезненно уволить. :-)
В ролике выше показаны отличия в понимании разными людьми одних и тех же слов.
Для одного параллельные — непременно непересекающиеся прямые, и перпендикулярность определена исключительно для прямых. Для другого — любые линии, которые всюду находятся на одном и том же расстоянии друг от друга («параллельные кривые»), а перпендикулярность определяется локально (в данной точке строим касательные к кривым и измеряем угол между ними, если 90° — кривые перпендикулярны).
Для одного прозрачный — это тот, который не видно, вообще не видно, а видно то, что находится за ним. Для другого прозрачный включает и «полупрозрачный» тоже.
Для одного котёнок — это объект трёхмерный, ну ладно, изображение может быть двумерным, но линия-то объект строго одномерный и не может быть в форме двумерного (про кривую Пеано он, предположим, не слышал). Для другого — линия — это как след от грифеля карандаша, вполне имеет осязаемую ширину, и можно сделать её любой формы, например, в форме котёнка.
И вывод: прежде, чем обсуждать, нужно договориться об определениях, и потом следовать им. Чтобы одни и те же слова понимать одинаково.
Вообще у этого «эксперта» какое-то ужасно узкое и закостенелое понимание мира. Дальше своих школьных знаний он ничего не приемлет. Наверное, на того, кто ему расскажет, будто можно определить операцию квадратного корня из отрицательных чисел, он тоже посмотрит как на идиота.
Для одного параллельные — непременно непересекающиеся прямые, и перпендикулярность определена исключительно для прямых. Для другого — любые линии, которые всюду находятся на одном и том же расстоянии друг от друга («параллельные кривые»), а перпендикулярность определяется локально (в данной точке строим касательные к кривым и измеряем угол между ними, если 90° — кривые перпендикулярны).
Для одного прозрачный — это тот, который не видно, вообще не видно, а видно то, что находится за ним. Для другого прозрачный включает и «полупрозрачный» тоже.
Для одного котёнок — это объект трёхмерный, ну ладно, изображение может быть двумерным, но линия-то объект строго одномерный и не может быть в форме двумерного (про кривую Пеано он, предположим, не слышал). Для другого — линия — это как след от грифеля карандаша, вполне имеет осязаемую ширину, и можно сделать её любой формы, например, в форме котёнка.
И вывод: прежде, чем обсуждать, нужно договориться об определениях, и потом следовать им. Чтобы одни и те же слова понимать одинаково.
Вообще у этого «эксперта» какое-то ужасно узкое и закостенелое понимание мира. Дальше своих школьных знаний он ничего не приемлет. Наверное, на того, кто ему расскажет, будто можно определить операцию квадратного корня из отрицательных чисел, он тоже посмотрит как на идиота.
«постараться выполнить данную задачу» — а после выполнения узнать, что заказчик хотел совершенно не это и не так? На мой взгляд это плохой вариант, который затягивает и сроки и добавляет кучу ненужной работы. Выполнять задачу пока она не понята одинаково обеими сторонами — точно непродуктивно, а вероятно что и некомпетентно, из серии — угадал-не угадал.
Эксперт, за весь разговор ни разу не задавший вопроса «зачем».
Я часто задаю этот вопрос, они бесятся с него -((((
Стараюсь отучаться.
Гораздо лучше вопрос: «Какие у вас ожидания», или «Допустим, все получится, опишите что тогда?»
Стараюсь отучаться.
Гораздо лучше вопрос: «Какие у вас ожидания», или «Допустим, все получится, опишите что тогда?»
Ну задавать «зачем» — бесит всех
Нужно по другому. Для чего вы это хотите? что вам это даст? Какая цель этого действа? Что в конце должно быть? и т.д.
Ответ должен быть не «я хочу котенка», а «я хочу продать это в майкрософт».
Нужно по другому. Для чего вы это хотите? что вам это даст? Какая цель этого действа? Что в конце должно быть? и т.д.
Ответ должен быть не «я хочу котенка», а «я хочу продать это в майкрософт».
Начальники и заказчики вырываются на верхушку пищевой цепи благодаря своей смелости.
Смелость часто подразумевает низкий уровень осознанности.
Это означает, что вопрос: «Что хочешь, что даст, какая цель, что в конце» ставит их в тупик! Да-да!
А вот что они ждут, или как они видят успех — обычно могут рассказать -))))
Смелость часто подразумевает низкий уровень осознанности.
Это означает, что вопрос: «Что хочешь, что даст, какая цель, что в конце» ставит их в тупик! Да-да!
А вот что они ждут, или как они видят успех — обычно могут рассказать -))))
UFO just landed and posted this here
Как вариант.
Также не могу не отметить, что первоисточник лучше экранизации: Совещание (профессионал).
UFO just landed and posted this here
Ну это и не дичь.
Дичь это фильтр на видео по поиску лады баклажан за 2к рублей
Дичь — рекламные щиты в лифт за 5к рублей с полной разработкой сервера и т.д.
Дичь — сделать убийцу фейсбука
и т.д.
Дичь это фильтр на видео по поиску лады баклажан за 2к рублей
Дичь — рекламные щиты в лифт за 5к рублей с полной разработкой сервера и т.д.
Дичь — сделать убийцу фейсбука
и т.д.
Если касается разработки, то заказчик в какой-то момент осознает дичь и все проблемы с нею связанные. При этом обвиняет в ней исполнителей, в зависимости от наглости клиента или начальника обвинения находятся в диапазоне от: «Я такого не предлагал» до «Да, это была моя идея, но вы как спецы должны были меня переубедить.»
Что интересно, даже собственноручно его сиятельством подписанные бумажки не действуют! Ответ может быть такой, например: «Я не осознавал, что подписываю, вы просто воспользовались моим непониманием тонкостей и получили утверждение при помощи хитрости!»
Что интересно, даже собственноручно его сиятельством подписанные бумажки не действуют! Ответ может быть такой, например: «Я не осознавал, что подписываю, вы просто воспользовались моим непониманием тонкостей и получили утверждение при помощи хитрости!»
боится, что завалит на первом же допросеПолагаю что если его возьмут на работу после такого, то слово сменит свою первую букву. Очень уж это пром. шпионажем со стороны заказчика отдаёт.
Есть ГОСТ 34.602-89. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Писал несколько ТЗ по нему. Получилось очень даже ничего.
А то, что автором приводится в начале темы — это не ТЗ, это заявление о намерениях, не имеющие с ТЗ ничего общего.
Писал несколько ТЗ по нему. Получилось очень даже ничего.
А то, что автором приводится в начале темы — это не ТЗ, это заявление о намерениях, не имеющие с ТЗ ничего общего.
Спасибо, что напомнили про ГОСТ.
У меня есть заказчики, которые кидают в меня ТЗ по ГОСТу, или детально документированным API на 200 страницах и просят разобраться и объяснить разрабам, а что делать собственно надо -)
У меня есть заказчики, которые кидают в меня ТЗ по ГОСТу, или детально документированным API на 200 страницах и просят разобраться и объяснить разрабам, а что делать собственно надо -)
Если ТЗ по ГОСТ, то адекватному разработчику ничего дополнительно объяснять не надо. Если надо — ТЗ таки запорото или у вас не разработчик, а кодер (оператор среды разработки).
Читал на днях книгу «Архитектура корпоративных приложений» за авторством Дино Эспозито. Очень многие моменты разработки архитектуры пересекаются с ТЗ по ГОСТ (пусть и называются по разному).
Был у меня случай, когда сеть мебельных магазинов захотела все же свести все звонки в единую сеть, а не как у них было: три городские линии, десяток сотовых и независимый call центр. Когда я сел с директором за один стол и попытался составить ТЗ или хотя бы нарисовать схему логики работы офисной АТС, я увидел печаль в глазах. Мне с десяток раз был задан вопрос: «Сколько это будет стоить?». На мои аргументы, что проект может быть оценен примерно только после составления ТЗ, был ответом еще более печальный взгляд.
Прошло более полугода и я до сих пор наблюдаю на известном сайте поиска работников вакансию сисадмина с глубоким знанием Asterisk за корок сопеек. А клиенты так и звонят то в call center, то на сотовый кладовщику, то на городской бухгалтеру…
Прошло более полугода и я до сих пор наблюдаю на известном сайте поиска работников вакансию сисадмина с глубоким знанием Asterisk за корок сопеек. А клиенты так и звонят то в call center, то на сотовый кладовщику, то на городской бухгалтеру…
Ну т.е. попытка составить ТЗ привела к потере заказа?
На десятый вопрос о стоимости реализации я ответил: «от 100 до 500 тысяч, в зависимости от объема работ. Точнее скажем после утверждения ТЗ». На этом общение закончилось. Так что скорее жадность, раз они до сих пор ищут мальчика-все-в-одном
а чего вы им не сделали business case, который бы показал их текущие потери и обосновал бы ваши работы как вполне рентабельные?
Иногда дешевле не браться за определенную работу, чем потратить на доказательство того, что заказчику это нужно, свое время, которое тоже стоит денег.
ну так вы уже потратили значительно, судя по тому, что вам вопрос про деньги успели задать десять раз
может стоило после второго раза остановиться и накидать расчёты на салфетке?
может стоило после второго раза остановиться и накидать расчёты на салфетке?
3 часа набросков на 3 листах А4. Отдал схемы местному сисадмину, чтобы он с директором утвердил желаемые варианты работы (1-2 варианта переадресаций). После разговаривал с директором пару раз.
По итогу, директор хочет возложить создание АТС с распределенной сетью магазинов и call-центром на сисадмина с з.п. 30 тыс :)
По итогу, директор хочет возложить создание АТС с распределенной сетью магазинов и call-центром на сисадмина с з.п. 30 тыс :)
«Я тебя полюбил, я тебя научу» © Уэф
Начинать надо с изучения сегмента рынка на котором
собираешься работать. Сбор информации, анализ.
Идти на встречу с заказчиком желательно после
синтеза собственного видения проблемной области.
В идеале — прототипировать пару-тройку экранов, еще лучше
это сделать совместно с дизайнером, чтобы глаз радовало.
Имея на руках презентацию и прототип легче перевести разговор с заказчиком
в конструктивное русло. На самом деле, рынки уже сложились.
Обзоры есть в продаже. Нормативная база также. Часть инфы гуглится.
Нарабатывать базу прототипов можно и заранее, не дожидаясь
звонков от клиентов. Добавлю, что автору удалось в статье очень логично
и талантливо в рамках своей собственной уникальной системы понятий описать процесс коммуникации
с клиентом, но к техническому заданию, как к регламентному документу
это не имеет отношения. Скорее протоколы, спецификации, психологические заметки,
но не ТЗ.
Начинать надо с изучения сегмента рынка на котором
собираешься работать. Сбор информации, анализ.
Идти на встречу с заказчиком желательно после
синтеза собственного видения проблемной области.
В идеале — прототипировать пару-тройку экранов, еще лучше
это сделать совместно с дизайнером, чтобы глаз радовало.
Имея на руках презентацию и прототип легче перевести разговор с заказчиком
в конструктивное русло. На самом деле, рынки уже сложились.
Обзоры есть в продаже. Нормативная база также. Часть инфы гуглится.
Нарабатывать базу прототипов можно и заранее, не дожидаясь
звонков от клиентов. Добавлю, что автору удалось в статье очень логично
и талантливо в рамках своей собственной уникальной системы понятий описать процесс коммуникации
с клиентом, но к техническому заданию, как к регламентному документу
это не имеет отношения. Скорее протоколы, спецификации, психологические заметки,
но не ТЗ.
Тоже пытаюсь заставить заказчиков сформулировать ТЗ ну хоть как нибудь. Последнее время нравится идея писать ТЗ в виде нумерованного иерархического списка, где можно каждое слово верхнего уровня «разжевать» на нижнем уровне подробнее. Ну, вроде бы это просто — напиши идею в 5 словах. Потом ниже каждое слово опять распиши 5ю словами (ну, или меньше), и еще детальнее ниже, пока «детали не закончатся» на своём уровне мышления.
Даже сервис сделал совсем недавно на эту тему (androrder.xyz/h4w), но судя по статистике создаваемых проектов пользователями — идея им не очень нравится и составление ТЗ останавливается на 3-4 строчке.
Даже сервис сделал совсем недавно на эту тему (androrder.xyz/h4w), но судя по статистике создаваемых проектов пользователями — идея им не очень нравится и составление ТЗ останавливается на 3-4 строчке.
Вопрос формулирования ТЗ несколько глубже. Нужно взять на себя ответственность и напрячь мозг. Это не легко, люди этого избегают.
Это вполне понятно, но надо же как-то сподвигнуть заказчика хоть что-то рассказать подробнее, особенно, если первичная тема запроса реально интересна. Вот и задача — как выудить инфо из заказчика не напрягая его. Чтобы как на допросе со спец средствами на вопросы ему отвечалось легко, без задержек…
Ну вот я предлагаю рассказать о жизни.
Часто рассказ о жизни заказчика (чем он живет, кем работает, какое образование, как ему пришла эта идея, откуда, что он ждет от этого проекта) помогает в составлении правильного ТЗ лучше чем наличие ясных целей и задач.
Ведь они могут быть ложными, а история жизни обычно не врет -)
Часто рассказ о жизни заказчика (чем он живет, кем работает, какое образование, как ему пришла эта идея, откуда, что он ждет от этого проекта) помогает в составлении правильного ТЗ лучше чем наличие ясных целей и задач.
Ведь они могут быть ложными, а история жизни обычно не врет -)
У тебя на главной (https://androrder.xyz/) кодировка не указана. FF почему-то кирилицу ISO использует в этом случае, вместо utf-8.
ага Тз правда получаются жутковаты на вилд особенно когда видишь по 8-10 уровней иерархии, но жизннь облегчает радикально
реализация им не нравится, а не идея. Идея-то как раз ничего.
Спасибо за статью, словно побывал на той стороне процесса.
Но вопрос один имеется: «ТЗ высокой четкости» для кого?
Я разработчик и бывало такое когда ТЗ утвердило руководство, акцептовал начальник отдела аналитики собрали все подписи с клиента, а потом удаленький разработчик задает маленький вопрос и все летит в там-тарары.
Но вопрос один имеется: «ТЗ высокой четкости» для кого?
Я разработчик и бывало такое когда ТЗ утвердило руководство, акцептовал начальник отдела аналитики собрали все подписи с клиента, а потом удаленький разработчик задает маленький вопрос и все летит в там-тарары.
Ребят, тут ведь все прозрачно. У клиента «проблема/желание». С нас выслушать его и «родить решение». А затем зафиксировать его в ТЗ. Я бы сразу разделил и не смешивал эти направления.
Когда клиент сам пытается родить именно решение — все упирается в его скилл. Как правило он никакой, оттуда и решения никакие (то розовую кнопку по центру экрана попросит, то еще что). Но это не отменяет наличия у него проблемы или потребности.
Если клиент пришел и говорит: «Хочу, что бы вы мне голову отрубили», то надо на автомате уточнить: «А исходя из чего Вы приняли такое решение? Какую жизненную задачу мы закроем? Какие еще решение рассматривали?» и т.д. т.п. Финансово частенько выгодно сказать: «Так точно! Будет сделано!», а потом на возражение клиента выдавать: «ВСЁ ПО ТЗ!». Но это не по «нашему» =)
Мне пока везет и клиенты с большим пониманием и доверием относятся к тому, что с них проблема/окружение/пожелания, а с меня поиск решения. Так не с первой встречи, но в процессе данный подход очевидно побеждает «Сделайте нам вот сюда вот именно вот так! Сколько стоит?» (если речь про долгосрочные отношения).
Когда клиент сам пытается родить именно решение — все упирается в его скилл. Как правило он никакой, оттуда и решения никакие (то розовую кнопку по центру экрана попросит, то еще что). Но это не отменяет наличия у него проблемы или потребности.
Если клиент пришел и говорит: «Хочу, что бы вы мне голову отрубили», то надо на автомате уточнить: «А исходя из чего Вы приняли такое решение? Какую жизненную задачу мы закроем? Какие еще решение рассматривали?» и т.д. т.п. Финансово частенько выгодно сказать: «Так точно! Будет сделано!», а потом на возражение клиента выдавать: «ВСЁ ПО ТЗ!». Но это не по «нашему» =)
Мне пока везет и клиенты с большим пониманием и доверием относятся к тому, что с них проблема/окружение/пожелания, а с меня поиск решения. Так не с первой встречи, но в процессе данный подход очевидно побеждает «Сделайте нам вот сюда вот именно вот так! Сколько стоит?» (если речь про долгосрочные отношения).
1. Клиент далеко не всегда понимает свою проблему или желание, а иногда даже скрывает ее! Типа, чтобы было дешевле или по другим причинам.
2. Иногда кажется, что проблема или желание яснее ясного, все по полочкам разложено и записано, а потом оказывается, что что-то упустил.
3. Часто в ходе разработки проблема или желание меняются до неузнаваемости, но не всегда заказчик это осознает. Ему кажется, что всегда он хотел именно этого, просто вы не поняли.
4. Изменения проблем и желаний могут быть по массе причин: рынок изменился, осознание изменилось, компания изменилась, мода изменилось.
Так что вам ооочень сильно везет -)))) Очень!
2. Иногда кажется, что проблема или желание яснее ясного, все по полочкам разложено и записано, а потом оказывается, что что-то упустил.
3. Часто в ходе разработки проблема или желание меняются до неузнаваемости, но не всегда заказчик это осознает. Ему кажется, что всегда он хотел именно этого, просто вы не поняли.
4. Изменения проблем и желаний могут быть по массе причин: рынок изменился, осознание изменилось, компания изменилась, мода изменилось.
Так что вам ооочень сильно везет -)))) Очень!
Ох уж этот замечательный третий пункт… вроде и делаешь всё как просили, и записываешь всё по буквам, а в итоге — сам дурак… Так иногда и хочется с диктофоном к некоторым товарищам приходить…
1. Вот это зря. Бизнес прекрасно понимает, где у него жмет. Иначе бы не началось телодвижение. Да, сформулировано может быть как в старом анекдоте. Но аналитик должен докопаться до истины с приемлемыми затратами, ну работа такая.
2. В любых договоренностях так может быть, очевидно.
3 и 4. А никто и не говорит что требования в камне. Они живые. Один разок я полгода писал ТЗ для лаборатории, а как подписали все шишки, смена законодательства и ТЗ в утиль. Я не расстроился ;)
Везет мне как всем, вопрос в постановке задачи/роли аналитика ;)
2. В любых договоренностях так может быть, очевидно.
3 и 4. А никто и не говорит что требования в камне. Они живые. Один разок я полгода писал ТЗ для лаборатории, а как подписали все шишки, смена законодательства и ТЗ в утиль. Я не расстроился ;)
Везет мне как всем, вопрос в постановке задачи/роли аналитика ;)
Бизнес прекрасно понимает, где у него жмет. Иначе бы не началось телодвижение.
Это выдает в вас сторонника теории рационального поведения экономических субьектов.
Есть немало современных экономистов, в том числе нобелевские лауреаты, которые убедительно доказываеют иррациональность поведения экономических субьектов. На вскидку можно почитать: Роба Шиллера, Джозефа Стиглица, Дэна Канемана, Джо Аркелофа.
Короче, телодвижение может начаться не из-за прекрасного понимания. А просто вот так начаться иррациональненько -)
Это выдает в вас сторонника теории рационального поведения экономических субьектов.
Нет не выдает ^^ Условно половину обращений я закрываю, мол «нет проблем», «переложить на других», «в данных условиях/формулировках/требованиях не решаются», «решаются штатными средствами», «решаются организационно/юридически/другое».
Для меня обращение бизнеса — это входящая задача. Решением задачи может быть в итоге ТЗ. Именно может быть, а не обязано.
Т.е. вы признаете, что бизнес генерирует часто рандомные задачи, а не те которые вызваны экономической целесообразностью?
Именно об этом я и написал выше. Но это нормально. Что то из обращения пойдет в ТЗ на реализацию, что то «забреется». Не вижу проблем, оно так устроено и в других отраслях.
Я признаю! Мало того, могу дать простое тому объяснение.
«Бизнес» это не абстрактный конь в вакууме — это немножко другие, но все же люди обреченные доказывать свои высокие зарплаты своей часто сомнительной нужностью.
Инициатива проявлена? Суета создана? Что там технари что-то нарисовать не могут? А почему? Вот оно как… Ну не могут так не могут… ;)
Через так, получают дополнительную информацию, которую добывать сложно/долго/нудно/скучно/лень… И, на новый круг!
Для людей, которые любят и делают дело, бессмысленные совещания — помеха, для такого «бизнеса» — хлеб насущный.
«Бизнес» это не абстрактный конь в вакууме — это немножко другие, но все же люди обреченные доказывать свои высокие зарплаты своей часто сомнительной нужностью.
Инициатива проявлена? Суета создана? Что там технари что-то нарисовать не могут? А почему? Вот оно как… Ну не могут так не могут… ;)
Через так, получают дополнительную информацию, которую добывать сложно/долго/нудно/скучно/лень… И, на новый круг!
Для людей, которые любят и делают дело, бессмысленные совещания — помеха, для такого «бизнеса» — хлеб насущный.
1. Объяснения лежат глубже, т.к. рациональных людей вообще не существует, что подтверждается массой воспроизводимых экспериментов.
2. «Коммуникация важнее документации» — это факт.
2. «Коммуникация важнее документации» — это факт.
>рациональных людей вообще не существует
Интересная мысль. Выстраданная или преобретенная? На переговорах попросил бы определить «рациональность» с Вашей кочки зрения. :)
>На вскидку можно почитать: Роба Шиллера, Джозефа Стиглица, Дэна Канемана, Джо Аркелофа.
Можно поконкретнее — две три книги из серии 'mast have'? С ответом не тороплю.
Интересная мысль. Выстраданная или преобретенная? На переговорах попросил бы определить «рациональность» с Вашей кочки зрения. :)
>На вскидку можно почитать: Роба Шиллера, Джозефа Стиглица, Дэна Канемана, Джо Аркелофа.
Можно поконкретнее — две три книги из серии 'mast have'? С ответом не тороплю.
Мысль прочитанная в книжках -)
По нобелевским лауреатам последних лет:
1. Шиллер «Иррациональный оптимизм» — там как инвесторы принимают решения
2. Стиглиц «Крутое пике» — о последствиях веры в «рациональность» рынков
3. Кругман «Выход из кризиса есть» — о том что можно сделать для экономики, поняв что экономические субъекты иррациональны
4. Шиллер и Аркелов «Spiritus Animalis» — как иррациональность правит экономикой
5. Канеман «Принятие решений в условиях неопределенности» — о том, как люди ошибаются в прогнозах и почему.
6. Канеман «Думай медленно, решай быстро» — название на русском абсолютно неправильное, но книга в продолжение темы принятия решений
И если хватит сил
Дэн Ариэли, думаю он тоже получит премию лет через 10:
1. Предсказуемая иррациональность
2. Позитивная иррациональность
3. Вся правда о неправде
По нобелевским лауреатам последних лет:
1. Шиллер «Иррациональный оптимизм» — там как инвесторы принимают решения
2. Стиглиц «Крутое пике» — о последствиях веры в «рациональность» рынков
3. Кругман «Выход из кризиса есть» — о том что можно сделать для экономики, поняв что экономические субъекты иррациональны
4. Шиллер и Аркелов «Spiritus Animalis» — как иррациональность правит экономикой
5. Канеман «Принятие решений в условиях неопределенности» — о том, как люди ошибаются в прогнозах и почему.
6. Канеман «Думай медленно, решай быстро» — название на русском абсолютно неправильное, но книга в продолжение темы принятия решений
И если хватит сил
Дэн Ариэли, думаю он тоже получит премию лет через 10:
1. Предсказуемая иррациональность
2. Позитивная иррациональность
3. Вся правда о неправде
UFO just landed and posted this here
Потому, что не погрузившись в проблему цели и задачи сформулировать не удается!
Иногда формулирую их на 2-ом, 3-ем этапе.
Однако тестовый контент может все в корне поменять!
Иногда формулирую их на 2-ом, 3-ем этапе.
Однако тестовый контент может все в корне поменять!
UFO just landed and posted this here
У аналитика есть заказчик.
Бывают уникальные заказчики, которые сразу в состоянии увидеть цели и задачи.
Они на то и уникальны, что встречаются редко.
Поэтому на практике цели и задачи формулируются в процессе, а не в начале.
Однако разработчик их видит в самом начале обычно -)
Бывают уникальные заказчики, которые сразу в состоянии увидеть цели и задачи.
Они на то и уникальны, что встречаются редко.
Поэтому на практике цели и задачи формулируются в процессе, а не в начале.
Однако разработчик их видит в самом начале обычно -)
UFO just landed and posted this here
Я понимаю о чем вы.
При этом не будем забывать про классический этап «исследование предметной области».
Как-то все его опускают и считают бесплатным. Типа исследование предметной области и погружение в проблематику для джуниоров, а мы то профессионалы!
В 1998 меня учили в институте исследовать предметную область.
В 2008 мне казалось, что я сразу могу круто сформулировать цели и задачи для чего угодно.
А сейчас в 2017 я понимаю, что идти по ложному направлению совершенно нормально, главное не заходить далеко и двигаться маленькими шагами.
При этом не будем забывать про классический этап «исследование предметной области».
Как-то все его опускают и считают бесплатным. Типа исследование предметной области и погружение в проблематику для джуниоров, а мы то профессионалы!
В 1998 меня учили в институте исследовать предметную область.
В 2008 мне казалось, что я сразу могу круто сформулировать цели и задачи для чего угодно.
А сейчас в 2017 я понимаю, что идти по ложному направлению совершенно нормально, главное не заходить далеко и двигаться маленькими шагами.
Ну с моей колокольни проблема несколько в другом.
Обычно происходит так.
Есть проект. В начале «исследуют предметную область», «составляют требования» и т.д.
И типа пока код как-бы писать не надо, т.к. «мы исследуем».
Потом когда уже таки да все исследовали/изучили начинаю/ем писать код.
И тут ВНЕЗАПНО выясняется, все что исследовали/изучили ~80% можно просто выкинуть.
Т.к. увидев работающий прототип заказчик говорит, что здесь он думал другое, тут понял вот так.
А это вообще сделано не правильно, т.к. вы сделали как правильно (как написано в нормативных документах), а нам надо, как нужно (как мы в действительности работаем)
И происходит интерактивный процесс.
Прототип-> Уточнение->Прототип.
И так пока не закончатся деньги.
И это бы ничего, но обычно от 3 до 6 месяцев, как раз уходит на «исследования».
А потом за 3-4 месяца нужно сделать продукт.
Поэтому я за Agile. Т.е. заказчик должен как можно раньше увидеть прототип, чтобы он мог на что-то опереться и высказать, свое «фи».
Обычно происходит так.
Есть проект. В начале «исследуют предметную область», «составляют требования» и т.д.
И типа пока код как-бы писать не надо, т.к. «мы исследуем».
Потом когда уже таки да все исследовали/изучили начинаю/ем писать код.
И тут ВНЕЗАПНО выясняется, все что исследовали/изучили ~80% можно просто выкинуть.
Т.к. увидев работающий прототип заказчик говорит, что здесь он думал другое, тут понял вот так.
А это вообще сделано не правильно, т.к. вы сделали как правильно (как написано в нормативных документах), а нам надо, как нужно (как мы в действительности работаем)
И происходит интерактивный процесс.
Прототип-> Уточнение->Прототип.
И так пока не закончатся деньги.
И это бы ничего, но обычно от 3 до 6 месяцев, как раз уходит на «исследования».
А потом за 3-4 месяца нужно сделать продукт.
Поэтому я за Agile. Т.е. заказчик должен как можно раньше увидеть прототип, чтобы он мог на что-то опереться и высказать, свое «фи».
Я работаю и так и эдак.
В целом стараюсь договориться на стартовый этап недели на две как раз, чтобы увидеть прототип как можно скорее.
— по ТЗ работаю
— по Agile работаю
Разница стирается, если ТЗ маленькое и уменьшается в мини-спринт.
При этом все-таки вы поднимаете вопрос прогнозирования.
Допустим все по Agile, двигаемся мини-задачами, которые сразу подходят для внедрения.
Однако внедрение на стороне клиента не происходит с той скоростью, которую вы ожидали.
Сотрудники раскачиваются медленно.
И когда через 3-6 месяцев часть народа удается на систему пересадить, выясняется что был изначально выбран ложный путь. Причем понимание этого нарастает лавинообразно. Вот не было его и вдруг появилось, как мода или как кризис среднего возраста-)
В целом стараюсь договориться на стартовый этап недели на две как раз, чтобы увидеть прототип как можно скорее.
— по ТЗ работаю
— по Agile работаю
Разница стирается, если ТЗ маленькое и уменьшается в мини-спринт.
При этом все-таки вы поднимаете вопрос прогнозирования.
Допустим все по Agile, двигаемся мини-задачами, которые сразу подходят для внедрения.
Однако внедрение на стороне клиента не происходит с той скоростью, которую вы ожидали.
Сотрудники раскачиваются медленно.
И когда через 3-6 месяцев часть народа удается на систему пересадить, выясняется что был изначально выбран ложный путь. Причем понимание этого нарастает лавинообразно. Вот не было его и вдруг появилось, как мода или как кризис среднего возраста-)
UFO just landed and posted this here
Я разрабатываю аппаратно-программные платформы для управления силовой электроникой. В последнее время полюбил Jira, как средство для управления требованиями.
Т.е. каждое требование — это Issue. В описание обязательно должна быть прописана причина возникновения требования. Далее комментами выясняется и дополняется между всеми командами. В конце идет workflow по формальному review и approval.
Медленно, но верно. На основании требований создаются user stories и задания — каждое требование должно приводить к одному или более заданиям и каждое задание должно закрывать как минимум одно или несколько требований. Так появляется полная traceability от требований до svn.
Супер, хороший путь.
А что заказчик по жире говорит?
А что заказчик по жире говорит?
По жире ничего, так как основная нагрузка на мне — как менеджере управления требованиями — правильно сформулировать, разбить одно большое требование на несколько мелких, связать вместе, направить нужному спецу для комментов и т.д.
Как правило со стороны заказчика сидят несколько специалистов, которые только комментируют и утверждают требования. Поэтому нагрузка на каждого не такая большая и им собственно пофиг — то ли жира это, или что-то другое.
Самый неприятный вопрос к заказчику, как уже обсуждали выше — это "Зачем?". Вытягивать приходится за уши, граблями. И тогда вылазят такие интересные вещи, что жира постепенно превращается в кладезь мудрости.
На «Зачем?» могут ответить что-нибудь в духе, а почему вы спрашиваете? Или каким боком ответ на этот вопрос влияет на работу?
Да, влияет. Мы скорее всего ваше объяснение поняли неправильно, и если мы будем делать так, вы заплатите лишние деньги за переделывание, но если вы объясните, зачем это вам нужно, понять вас правильно будет гораздо проще и максимально вероятно, что мы сделаем сразу именно так, как вы имели ввиду.
От меня заказчикам так легко не уйти. Мы как бы под одной крышей. По теории каждое требование — это желание, потребность. А потребность возникает по какой-то причине. Если причины нет, то и потребность не возникнет. Следовательно ответ на вопрос "Зачем" позволяет лучше определить причины возникновения требования и в конце концов выяснить, насколько оно важно заказчику.
Часто в процессе выяснения "зачем" требование меняется до неузнаваемости.
Например в процессе обсуждения одного из самого простых требований: "Устройство должно работать в диапазоне температур от -25°C до +55°C" выяснилось, что:
- устройство будет эксплуатроваться только в кондиционированных помещениях, но
- по всему миру, а индусы — теплолюбивые люди и при 20° им холодно, поэтому они отключают кондиционер
- часто это требование стоит в клиентских спецификациях, когда система с устройством сдается под ключ
- другие аналогичные устройства от конкурентов имеют такие же рейтинги — чего наше должно быть хуже?
- +55°C удовлетворит 80% текущих клиентов, оставшиеся 20% требуют +65°.
- есть стандарт МЭК, по которому -25°C...+55°C — это стандартный ряд, а допустим -25°C...+60°C — это уже не рекомендуемый диапазон.
И так далее. В результате это очень сильно влияет на выбор решения, даже если требование в результате не изменяется.
UFO just landed and posted this here
Смеялся от души, жизненно!
Из недавнего прошлого. Средней величины компания, хочет новый лендинг. Пытаюсь набросать бриф. В каждой итерации постоянно появляются всё новые и новые крупные фичи. При этом всё время звучит один и тот же вопрос «а сколько всё это будет стоить». На что я постоянно отвечаю «давайте сперва определимся, что вы хотите в виде ТЗ».
На 3-4 итерации меня спросили «а у вас есть рыба ТЗ или может откуда-то это можно скачать?», на что я сидел с выражением «рука-лицо» и ответил сухо «такого не может быть в принципе» и, понимая неизбежность нечеловеческих затрат времени на детализацию ТЗ, посоветовал им нанять аналитика, если у них нет квалифицированного человека, готового ответственно отнестись к проектированию.
Тем не менее, через месяц мне прислали содранное откуда-то замшелое ТЗ со своими правками, в которых всё равно ничего не было написано про те фичи, о которых мне рассказывали ранее. Зато было пожелание поддерживать IE 5.0, Firefox 1.0, Chrome 5.0 и какой-то набор диких разрешений мобильных устройств и адаптивную верстку, при этом имея только один макет дизайна под 1280px.
На это мне ничего не оставалось сделать, как назвать с потолка сумму денег, окупившую бы весь гемор по этому ТЗ и серию вопросов «я правильно понял, что вы хотите то-то и то-то?». Там ошалели от стоимости. И конечно же оказалось, что мало чего нужно было, но дополнительной инфы так и не предоставили.
Как итог, я написал от всего сердца, что далее есть только одна возможность общения со мной на тему ТЗ — платить деньги за его составление. Либо не общаться со мной, а заплатить их аналитику, как делают все нормальные люди. В противном случае не смогу считать себя профессионалом, за результат и претензии не отвечаю, но деньги возьму вперед. Больше ответов пока не последовало.
Ах да. Вся это котовасия длилась полгода.
Из недавнего прошлого. Средней величины компания, хочет новый лендинг. Пытаюсь набросать бриф. В каждой итерации постоянно появляются всё новые и новые крупные фичи. При этом всё время звучит один и тот же вопрос «а сколько всё это будет стоить». На что я постоянно отвечаю «давайте сперва определимся, что вы хотите в виде ТЗ».
На 3-4 итерации меня спросили «а у вас есть рыба ТЗ или может откуда-то это можно скачать?», на что я сидел с выражением «рука-лицо» и ответил сухо «такого не может быть в принципе» и, понимая неизбежность нечеловеческих затрат времени на детализацию ТЗ, посоветовал им нанять аналитика, если у них нет квалифицированного человека, готового ответственно отнестись к проектированию.
Тем не менее, через месяц мне прислали содранное откуда-то замшелое ТЗ со своими правками, в которых всё равно ничего не было написано про те фичи, о которых мне рассказывали ранее. Зато было пожелание поддерживать IE 5.0, Firefox 1.0, Chrome 5.0 и какой-то набор диких разрешений мобильных устройств и адаптивную верстку, при этом имея только один макет дизайна под 1280px.
На это мне ничего не оставалось сделать, как назвать с потолка сумму денег, окупившую бы весь гемор по этому ТЗ и серию вопросов «я правильно понял, что вы хотите то-то и то-то?». Там ошалели от стоимости. И конечно же оказалось, что мало чего нужно было, но дополнительной инфы так и не предоставили.
Как итог, я написал от всего сердца, что далее есть только одна возможность общения со мной на тему ТЗ — платить деньги за его составление. Либо не общаться со мной, а заплатить их аналитику, как делают все нормальные люди. В противном случае не смогу считать себя профессионалом, за результат и претензии не отвечаю, но деньги возьму вперед. Больше ответов пока не последовало.
Ах да. Вся это котовасия длилась полгода.
Классика жанра -)
Но это вы еще не стартанули. У меня есть кейсы, где пол года согласовывали ТЗ и стартанули.
Вот тогда начинается самая мякатка -)
Но это вы еще не стартанули. У меня есть кейсы, где пол года согласовывали ТЗ и стартанули.
Вот тогда начинается самая мякатка -)
У меня пока мало опыта в таких делах, но что-то неладное почуял и решил, что лучше пусть уйдут, чем потом мне будут трахать мозг еще неизвестно сколько.
Больше всего умилило во всём этом не столько отсутствие понимания того, что хотят, сколько ощущение, что никому на самом деле этот проект не нужен, если учесть постоянные попытки спихнуть на меня написание ТЗ и отстраненность от этого процесса.
Больше всего умилило во всём этом не столько отсутствие понимания того, что хотят, сколько ощущение, что никому на самом деле этот проект не нужен, если учесть постоянные попытки спихнуть на меня написание ТЗ и отстраненность от этого процесса.
Ну блин, слушайте же вашего заказчика.
Если заказчик просит не ТЗ, а смету, то ему и нужно предоставить смету.
Это такая табличка с укрупнёнными фичами. Такая-то фича будет стоить столько-то и займёт столько-то времени, а следующая — столько-то и столько-то. С пояснением «в стандартной комплектации».
Дальше, если фича реально нужна, начинается обсуждение «стандартной комплектации». Это уже подфичи.
Ну я понимаю, что если вы конкретно ту или иную фичу никогда не делали, то и оценить её сходу, а тем более аргументированно перечислить её «стандартную комплектацию», достаточно сложно. А если вообще не представляете, как это сделать — невозможно. Ну тут извините, аналитика кормит опыт, которого вам не хватило.
Если заказчик просит не ТЗ, а смету, то ему и нужно предоставить смету.
Это такая табличка с укрупнёнными фичами. Такая-то фича будет стоить столько-то и займёт столько-то времени, а следующая — столько-то и столько-то. С пояснением «в стандартной комплектации».
Дальше, если фича реально нужна, начинается обсуждение «стандартной комплектации». Это уже подфичи.
Ну я понимаю, что если вы конкретно ту или иную фичу никогда не делали, то и оценить её сходу, а тем более аргументированно перечислить её «стандартную комплектацию», достаточно сложно. А если вообще не представляете, как это сделать — невозможно. Ну тут извините, аналитика кормит опыт, которого вам не хватило.
Я его и слушал. Беда в том, что заказчик говорит что-то, что сам не понимает. Допустим «хотим АВ-тесты». Ок, раскройте тему. Что именно тестируем, как, какие метрики собираем. Опа, по ходу надо писать уже не совсем лендинг, а систему сбора статы, поскольку желаемое GA/ЯМ не предоставляют? Давайте конкретнее тогда опишем метрики. Вместо этого меня спрашивают сколько будет весь проект. Пардон, но мы только копнули, кусочек верхушки айсберга. И таких моментов дофига и больше.
Возникало ощущение, что заказчик как попугайчик выучил какие-то умные слова, но что это такое не понимает и хотел, чтобы я сам всё додумал)
Возникало ощущение, что заказчик как попугайчик выучил какие-то умные слова, но что это такое не понимает и хотел, чтобы я сам всё додумал)
Эмм ну я вот только вчера участвовал в отправлении сметы заказчику, который настаивал на том, что не хочет писать ТЗ, дайте смету!
Теперь он придирается к каждому пункту сметы: «а я не понимаю, почему эта фича займет у вас 6 часов, да это же 1,5 минуты»! -)))
Вот мы и думаем теперь, какие трудозатраты потребуются, чтобы с этим заказчиком спорить за каждый час в смете?
В целом отказ от ТЗ — уже симптом, который заставляет задуматься: а оно вам надо?
Теперь он придирается к каждому пункту сметы: «а я не понимаю, почему эта фича займет у вас 6 часов, да это же 1,5 минуты»! -)))
Вот мы и думаем теперь, какие трудозатраты потребуются, чтобы с этим заказчиком спорить за каждый час в смете?
В целом отказ от ТЗ — уже симптом, который заставляет задуматься: а оно вам надо?
Читал статью, а в голове упорно крутилось:
Лефортовский кондитерский комбинат. Спокойный среди бурь.
Извращенная логика — Искривленный мозг ))
ТЗ — это рамки, устанавливаемые исполнителем для свой защиты. Начинать переговоры с защиты своих позиций — заведомо проигрышная тактика.
UFO just landed and posted this here
Правильно ли я вас понял, что:
1. Вы хотите знать какое потребуется время и сколько нужно ресурсов на то, что никак не сформулировано?
2. Вы хотите иметь ответственного партнера, которого при этом легко «ампутировать»?
1. Вы хотите знать какое потребуется время и сколько нужно ресурсов на то, что никак не сформулировано?
2. Вы хотите иметь ответственного партнера, которого при этом легко «ампутировать»?
если он мне тыкает ТЗ = отказ от ответственности = «признание, что проект он ни осилит, и заранее делает — больше бумаги чище ....»
Тех. задание — это тех. задание, а отказ от ответственности — это отказ от ответственности. Они не равны, не взаимозаменяемы, это не одно и тоже…
Подобные умозаключения не логичны. Ошибочны. Как следствие, остальные выводы ошибочны. Продолжать читать дальше этой строки, не имеет смысла…
UFO just landed and posted this here
Получается, что вы работаете с разработчиками только когда они у вас «под постоянным контролем» и платите им почасовую?
UFO just landed and posted this here
Это же прекрасная иллюстрация требований заказчика неадеквата! Спасибо за яркий пример.
У меня только один вопрос. Как вы сами считаете, применима ли ваша идеология в строительстве загородного дома, или при ремонте квартиры? И кто в этом случае несет расходы за материалы?
Т.е. вы хотите, чтобы компания-разработчик создала вам бизнес, взяла на себя все риски и отдала вам свой бизнес на блюдечке с голубой каемочкой?
Есть два пути: 1) идти на Freelance и самостоятельно нести там все риски того, что у вас возьмут предоплату и киданут или задолбаются от вас жёстко и пошлют подальше; 2) обращаться в компанию и смириться с тем, что она работает по бизнес-логике, и бегать за вами там никто не будет, и да, разработчики там работают профессионально, по ТЗ, по часам и с 5 и более заказчиками. Хотите индивидуальной работы? Отлично! Оплачиваете отдельную штатную единицу по часам с повышенной ставкой. И, конечно, никто вам никогда не даст возможности трахать мозги квалифицированному персоналу.
Есть два пути: 1) идти на Freelance и самостоятельно нести там все риски того, что у вас возьмут предоплату и киданут или задолбаются от вас жёстко и пошлют подальше; 2) обращаться в компанию и смириться с тем, что она работает по бизнес-логике, и бегать за вами там никто не будет, и да, разработчики там работают профессионально, по ТЗ, по часам и с 5 и более заказчиками. Хотите индивидуальной работы? Отлично! Оплачиваете отдельную штатную единицу по часам с повышенной ставкой. И, конечно, никто вам никогда не даст возможности трахать мозги квалифицированному персоналу.
Мне вот интересно с вами работает, кто-то на таких условиях? Звучит очень странно просто, что нет требований, но есть сумма, и она фиксирована, а требования нет. На качество работ, тогда сразу забить можно.
У меня два вопроса:
Заранее спасибо.
- какой версией Гугл Транслейта вы пользуетесь?
- сколько компаний\студий\фрилансеров вам требуется перебрать для запиливания всего проекта и сколько времени у вас уходит на согласование конечного ТЗ?
Заранее спасибо.
UFO just landed and posted this here
Вы путаете эмоциональные впечатления от процесса обсуждения с желанием разработчиков сэкономить всем время, тем самым позволив заработать всем больше денег. Какой же из вас предприниматель, если вы этого не понимаете?
В какой версии продукта код становится окончательным?
Её красота мешала вам отвечать на вопрос? ;)
Те московские разработчики пытались с вами по-человечески разговаривать, насколько я могу судить, не обращая внимания на ваш феерический клубок последствий отключения всех систем головного мозга, за исключением лимбической (сужу по вашему стилю изложения — не обижайтесь, вы в этом не одиноки — за пределы изобретения Гутенберга ещё многие люди на планете не выбрались).
Вам же стоит «немного» больше думатьо других людях.
Окончательное ТЗ при используемом подходе это исходный код
В какой версии продукта код становится окончательным?
красивая девочка «бизнес аналитик» с любимым вопросом «а Вамзачем»
Её красота мешала вам отвечать на вопрос? ;)
Те московские разработчики пытались с вами по-человечески разговаривать, насколько я могу судить, не обращая внимания на ваш феерический клубок последствий отключения всех систем головного мозга, за исключением лимбической (сужу по вашему стилю изложения — не обижайтесь, вы в этом не одиноки — за пределы изобретения Гутенберга ещё многие люди на планете не выбрались).
Вам же стоит «немного» больше думать
Ну, для композиторов у нас отдельный тариф — «Почасовой с двойной тарификацией за споры», и все довольны )
Открою вам пару страшных тайн из реальной жизни.
1. Заказная разработка — это тоже бизнес. Ну совсем грубо говоря, владелец такой конторы покупает время у своих сотрудников и продаёт его вам, с налогами и прибылью. Если он ошибся при оценке стоимости разработки, он покупает больше времени, но продаёт его вам за тот же фиксированный прайс. Таким образом, оплачивая лишние часы разработчиков из своего кармана.
2. Соответственно, предложенная вами схема без ТЗ, без четких требований к продукту, но с фиксированными сроками и ценой, проканает только с совсем неопытными фрилансерами. Каждый юный предприниматель один-два раза накалывается на проектах с отсутствием ТЗ и всё, резко перестаёт быть волшебником в голубом вертолёте.
3. Рынок качественной разработки — это рынок продавца. Нравится вам или нет. В любой грамотной конторе огромная куча входящих заявок сразу идёт в корзину, если заказчик выглядит, просто выглядит, неадкватом. Либо же, если у заказчика явно есть деньги, в смету закладываются трёхкратные риски и огромный бонус «за вредность». Так что вам придётся либо играть по правилам исполнителя, либо очень сильно переплачивать.
4. Чем дальше вы продвинулись по этапам разработки, тем больше вы влипли. Исполнитель свои деньги ну плюс-минус получил, пусть и без прибыли, а у вас пока на руках лишь частично готовый продукт, использовать который нельзя. Если вас осенит гениальная идея, или если в ТЗ обнаружится ошибка — не важно, по чьей вине, или по какой-то ещё причине вы решите поменять ТЗ или выдвинуть новые требования — вам вежливо улыбнуться, выдвинут смету на доп. работы и пригласят в кассу. Не нравится? До свидания.
5. Доделывать проект в другой компании будет кратно дороже — ну, потому что новым разработчикам нужно время, чтобы въехать в тематику. Не потому, что разработчики такие злые или жадные, просто см. п. 1.
5. Однако, многие владельцы компаний друг с другом знакомы хотя бы через третьи руки, и не обломаются позвонить бывшему исполнителю узнать вашу характеристику, если вы к ним придёте «дорабатываться». Если вы вели себя как м… к, с вами просто никто не будет разговаривать.
1. Заказная разработка — это тоже бизнес. Ну совсем грубо говоря, владелец такой конторы покупает время у своих сотрудников и продаёт его вам, с налогами и прибылью. Если он ошибся при оценке стоимости разработки, он покупает больше времени, но продаёт его вам за тот же фиксированный прайс. Таким образом, оплачивая лишние часы разработчиков из своего кармана.
2. Соответственно, предложенная вами схема без ТЗ, без четких требований к продукту, но с фиксированными сроками и ценой, проканает только с совсем неопытными фрилансерами. Каждый юный предприниматель один-два раза накалывается на проектах с отсутствием ТЗ и всё, резко перестаёт быть волшебником в голубом вертолёте.
3. Рынок качественной разработки — это рынок продавца. Нравится вам или нет. В любой грамотной конторе огромная куча входящих заявок сразу идёт в корзину, если заказчик выглядит, просто выглядит, неадкватом. Либо же, если у заказчика явно есть деньги, в смету закладываются трёхкратные риски и огромный бонус «за вредность». Так что вам придётся либо играть по правилам исполнителя, либо очень сильно переплачивать.
4. Чем дальше вы продвинулись по этапам разработки, тем больше вы влипли. Исполнитель свои деньги ну плюс-минус получил, пусть и без прибыли, а у вас пока на руках лишь частично готовый продукт, использовать который нельзя. Если вас осенит гениальная идея, или если в ТЗ обнаружится ошибка — не важно, по чьей вине, или по какой-то ещё причине вы решите поменять ТЗ или выдвинуть новые требования — вам вежливо улыбнуться, выдвинут смету на доп. работы и пригласят в кассу. Не нравится? До свидания.
5. Доделывать проект в другой компании будет кратно дороже — ну, потому что новым разработчикам нужно время, чтобы въехать в тематику. Не потому, что разработчики такие злые или жадные, просто см. п. 1.
5. Однако, многие владельцы компаний друг с другом знакомы хотя бы через третьи руки, и не обломаются позвонить бывшему исполнителю узнать вашу характеристику, если вы к ним придёте «дорабатываться». Если вы вели себя как м… к, с вами просто никто не будет разговаривать.
Ай, отлично сказано, спасибо. Разрешите утащить на цитаты?
Со всем согласен, при этом хочу обратить внимание на важную особенность, которую вы не учли.
Такие пассажиры далеко не всегда на первых встречах выглядят неадекватами или жесткими бизнесменами с яйцами (если орел я выиграл, а если решка ты проиграл).
На первых встречах они могут быть такие улыбчивые, позитивные, отзывчивые. Что-нибудь в духе:
— Да, я вас не обижу
— Да, от меня будет постоянный поток заказов
— Да, я всегда на стороне исполнителя
— Да, я ищу себе надежного партнера для долгосрочного сотрудничества
— Да, я не против ТЗ, просто пока толком непонятно и нужно нащупать рынок вместе с моим новым прекрасным партнером!
А если он еще и по знакомству пришел (а они любят прийти по знакомству), то эта конфетно-карамельная история бывает уносит в ванильные дали не только бывалых фрилансеров, но и опытных менеджеров и директоров малых и средних компаний, а бывает и крупных -)
Такие пассажиры далеко не всегда на первых встречах выглядят неадекватами или жесткими бизнесменами с яйцами (если орел я выиграл, а если решка ты проиграл).
На первых встречах они могут быть такие улыбчивые, позитивные, отзывчивые. Что-нибудь в духе:
— Да, я вас не обижу
— Да, от меня будет постоянный поток заказов
— Да, я всегда на стороне исполнителя
— Да, я ищу себе надежного партнера для долгосрочного сотрудничества
— Да, я не против ТЗ, просто пока толком непонятно и нужно нащупать рынок вместе с моим новым прекрасным партнером!
А если он еще и по знакомству пришел (а они любят прийти по знакомству), то эта конфетно-карамельная история бывает уносит в ванильные дали не только бывалых фрилансеров, но и опытных менеджеров и директоров малых и средних компаний, а бывает и крупных -)
Если вас осенит гениальная идея, или если в ТЗ обнаружится ошибка — не важно, по чьей вине, или по какой-то ещё причине вы решите поменять ТЗ или выдвинуть новые требования — вам вежливо улыбнуться, выдвинут смету на доп. работы и пригласят в кассу. Не нравится? До свидания.
Добавлю к этому, что вам скажут еще и сроки, которые могут быть весьма далекие т.к. команда, которая занималась вашим проектом должна перейти на другой проект, по которому уже оплачен аванс. Иными словами, в ряде случаев серьезные переработки в короткие сроки иногда сделать не получится даже за большие деньги т.к. у разработчиков другие планы.
Я давно уже сделал на сайте форму для заказчиков, которых прошу её заполнить.
Один из пунктов — «Подходящий вариант оплаты», с вариантами:
Разумеется, подавляющее большинство заказчиков выбирает второй пункт с фикс. суммой за проект.
Так вот если они выбирают его, но отлынивают от составления ТЗ в файле — я сразу им напоминаю об этом несоответсвии, и 95% «пропадают в дали», переставая тратить моё время. Но малая толика «адекватов» все-таки остается, и обычно это наиболее серьезные и платежеспособные заказчики.
И так же достаточно заказчиков осознанно выбирающих последний пункт. И если работа с ними начинается — им уже даже приятно делать скидки и округления сумм вниз.
Один из пунктов — «Подходящий вариант оплаты», с вариантами:
- «Еженедельная фиксированная оплата»
- «Фиксированная сумма за ТЗ, проект по согласованному техзаданию без доплат (требуется подробнейшее техзадание в файле)
- »Почасовая оплата каждого этапа по согласованному техзаданию с дополнительной почасовой оплатой любых изменений задания и переделок"
- «Стоимость рабочего часа со скидкой. Но большой\длительный проект (больше 99 рабочих часов) с поэтапной периодической оплатой тщательной работы с возможностью изменения техзадания и переделок»
Разумеется, подавляющее большинство заказчиков выбирает второй пункт с фикс. суммой за проект.
Так вот если они выбирают его, но отлынивают от составления ТЗ в файле — я сразу им напоминаю об этом несоответсвии, и 95% «пропадают в дали», переставая тратить моё время. Но малая толика «адекватов» все-таки остается, и обычно это наиболее серьезные и платежеспособные заказчики.
И так же достаточно заказчиков осознанно выбирающих последний пункт. И если работа с ними начинается — им уже даже приятно делать скидки и округления сумм вниз.
Заказчик с виртуальным кладбищем — приходил ко мне (встречались в кафе) очень давно один такой, более 5 лет назад. Правда, кладбище не людей, а животных. Он тогда ещё NDA захотел подписать на 5 лет на неразглашение идеи и говорил, что собрал уже пачку таких обязательств. Потом оказалось, что денег очень мало и даже снять офис затруднительно, т.к. дорогой интернет там будет, и т.д.… Потом ещё долго видел его объявление на фрилансерах. Может, это тот же с тех лет ходит?: )
Судя по результатам голосования — корень большей части проблем — траблы с коммуникацией.
Я поступаю проще. Первый документ, который я прошу от заказчика — бизнес требования. На этом этапе отсекаются неадекваты, не способные изложить на бумаге что им надо.
На втором шаге я переношу бизнес требования в вики и создаю к ним на форуме тему для проекта, в который постю все свои вопросы по бизнес требованиях в рамках полноты и логической непротиворечивости. На это стадии отсекаются неадекваты, осилившие бизнес требования, но не способные
Дальше просто интерактивный функциональный прототип реализующий бизнес требования.
Тест заказчиком
А дальше разработка на основании прототипа. Прототип выступает как часть ТЗ и даже даже дает метрику для оценки стоимости разработки.
На втором шаге я переношу бизнес требования в вики и создаю к ним на форуме тему для проекта, в который постю все свои вопросы по бизнес требованиях в рамках полноты и логической непротиворечивости. На это стадии отсекаются неадекваты, осилившие бизнес требования, но не способные
Дальше просто интерактивный функциональный прототип реализующий бизнес требования.
Тест заказчиком
А дальше разработка на основании прототипа. Прототип выступает как часть ТЗ и даже даже дает метрику для оценки стоимости разработки.
«Правильно ли я понимаю...» — шикарная формулировка. Постоянно её использую и не только в разговорах с заказчиком.
Sign up to leave a comment.
ТЗ высокой четкости