Часто бывает такое на работе.
Есть заказчик со стороны бизнеса, который в момент составления ТЗ не пишет какие-то детали.
После выполнения результата он что-то находит, что ему надо и что не указано в ТЗ.
Тут у него начинается претензия "где кнопка Скачать в Иксель?"
Ответ: в тз не было, сделаем через 2 недели, т.к. сейчас задачи идут по расписанию.
и тут он начинает свою балалайку "это и так очевидно, у нас во всех юаях это есть"
Иксель это как пример, в другом случае может быть фраза "без этого мы не можем работать"
И потом начинаются письма директору, типа мы не можем чтото делать т.к. айти нам не сделало тото и тото.
Понятно, что директор будет на стороне бизнеса, т.к. они деньги генерят.

Есть идеи как работать с такими персонажами?

Здравствуйте, e.thrash, Вы писали:

ET>Часто бывает такое на работе.
ET>Есть заказчик со стороны бизнеса, который в момент составления ТЗ не пишет какие-то детали.
ET>После выполнения результата он что-то находит, что ему надо и что не указано в ТЗ.
ET>Тут у него начинается претензия "где кнопка Скачать в Иксель?"
ET>Ответ: в тз не было, сделаем через 2 недели, т.к. сейчас задачи идут по расписанию.
ET>и тут он начинает свою балалайку "это и так очевидно, у нас во всех юаях это есть"
ET>Иксель это как пример, в другом случае может быть фраза "без этого мы не можем работать"
ET>И потом начинаются письма директору, типа мы не можем чтото делать т.к. айти нам не сделало тото и тото.
ET>Понятно, что директор будет на стороне бизнеса, т.к. они деньги генерят.

ET>Есть идеи как работать с такими персонажами?

1. брать задачу
2. прорабатывать самому
3. отдавать на согласование заказчику, отдельно прописав, что "кнопку Скачать делать не надо"
4. при разборках показывать согласованную задачу

это работает, но это не спасает.
даже если заказчик скажет "удалите все данные юзеров, нам они не нужны", то скоро он вернётся и будет утверждать, что такого не говорил и вообще имел в виду совсем другое.
при этом директор с большой вероятностью будет на его стороне, потому что директора не волнует, как всё работает.
мне нравится вариант: навязать свой процесс разработки.

Здравствуйте, e.thrash, Вы писали:

ET>Есть идеи как работать с такими персонажами?

Внимательно и заранее читать ТЗ. Все спорные моменты вроде отсутствия экспорта уточнять.

Здравствуйте, e.thrash, Вы писали:

ET>После выполнения результата он что-то находит, что ему надо и что не указано в ТЗ.
ET>Тут у него начинается претензия "где кнопка Скачать в Иксель?"

ET>Есть идеи как работать с такими персонажами?

"За ваши деньги — любой каприз!"

Здравствуйте, e.thrash, Вы писали:

ET>Есть идеи как работать с такими персонажами?

— Где кнопка на черновом варианте экрана (mock-up)? Где упоминание кнопки в тексте? Нет? В сад.

Здравствуйте, e.thrash, Вы писали:

ET>Есть заказчик со стороны бизнеса, который в момент составления ТЗ не пишет какие-то детали.
ET>Есть идеи как работать с такими персонажами?
Не давать им писать ТЗ. Подключать грамотных бизнес-аналитиков и проектировщиков интерфейсов. Если "без кнопки не работает", аналитик эту ситуацию поймает в полевом исследовании.

Здравствуйте, e.thrash, Вы писали:

ET>Есть идеи как работать с такими персонажами?
В таком случае либо грамотный бизнес аналитик поможет, либо не работать с такими заказчиками, либо арбитраж если деньги не платят .

Здравствуйте, e.thrash, Вы писали:

ET>Часто бывает такое на работе.
ET>Есть заказчик со стороны бизнеса, который в момент составления ТЗ не пишет какие-то детали.
ET>После выполнения результата он что-то находит, что ему надо и что не указано в ТЗ.
ET>Тут у него начинается претензия "где кнопка Скачать в Иксель?"
ET>Ответ: в тз не было, сделаем через 2 недели, т.к. сейчас задачи идут по расписанию.

ET>Есть идеи как работать с такими персонажами?

Все, что в ТЗ, — это объем работ, под который выделены часы и составлено расписание (расчет человеко-часов и т.п.). Один из вариантов контроля — для каждой фичи писать в user story её условия приема (ожидаемые результаты тестирования). Желательно подобные документы после планирования каждой итерации разработки (спринта) высылать заказчику "к вашему сведению". Это требует дисциплины со стороны PM, но это то, что работает в таких случаях. Потому что если ни в описании фичи, ни в тест-кейсах нет это функциональности, значит её не заказывали, ведь у заказчика есть копии документов, и он это видел. А всё, что не заказывали, но очень надо впихнуть впереди плановых задач — да, возможно, но тогда либо платите за переработку (если найдут желающих),либо откажитесь от чего-то другого в текущем релизе, ну либо подождать и добавить в список доработок.

ET>Есть идеи как работать с такими персонажами?

Делать доработки сверх ТЗ в обычном порядке. Хотят срочно — делать наценку за срочность.

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

Плюсую user story. Если заказчик опишет в одном из вариантов использования, что он делает экспорт, значит он нужен. Также полезно сообщить заказчику, что он оплатил только то, что есть в ТЗ, соответственно это он и получил. Хочет дополнительную функциональность — пусть платит (нужно вчера — пусть приходит позавчера или платит вдвойне и приходит завтра).

Здравствуйте, e.thrash, Вы писали:

ET>Есть идеи как работать с такими персонажами?

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

Здравствуйте, e.thrash,

ET>И потом начинаются письма директору, типа мы не можем чтото делать т.к. айти нам не сделало тото и тото.
ET>Понятно, что директор будет на стороне бизнеса, т.к. они деньги генерят.

Я правильно понимаю, что это внутренний проект (некая реинкарнация очередной опердени)?
Дык, эта.... А как вообще у вас происходит приемка? По принципу "нравится — не нравится"?

В моей Вселенной перед приемкой пишется и согласовывается с Заказчиком такой документ — ПиМИ (Программа и методика испытаний). В ней строго по пунктам ТЗ проверяется функционал того, что получилось. Если чего-то нет в ТЗ — ему неоткуда взяться в ПиМИ. Соответственно, в итоговом протоколе оно отражается не как "Замечания комиссии...", а как "Предложения" — "Рассмотреть возможность реализации того или сего." Ну и соответственно под то или се — планируется бюджет и сроки, и допсоглашение к договору.
Понятно, что для внутреннего заказчика допсоглашения не может быть, но дополнительные бюджет и сроки должны быть.

Здравствуйте, e.thrash, Вы писали:

ET>Часто бывает такое на работе.
Бывает, да.
ET>Есть заказчик со стороны бизнеса, который в момент составления ТЗ не пишет какие-то детали.
Сам грешен. Бизнес-аналитик, сидящий по соседству, может помочь.
ET>После выполнения результата он что-то находит, что ему надо и что не указано в ТЗ.
Это нормально.
ET>Тут у него начинается претензия "где кнопка Скачать в Иксель?"
И это нормально.
ET>Ответ: в тз не было, сделаем через 2 недели, т.к. сейчас задачи идут по расписанию.
Так, тикеты переупорядочили и не сношайте мне мозги.
ET>и тут он начинает свою балалайку "это и так очевидно, у нас во всех юаях это есть"
О, вы ещё и state of the art не исседовали перед началом работы.
ET>Иксель это как пример, в другом случае может быть фраза "без этого мы не можем работать"
Вполне вероятно, что так и есть.
ET>И потом начинаются письма директору, типа мы не можем чтото делать т.к. айти нам не сделало тото и тото.
И где он не соответствует истине?
ET>Понятно, что директор будет на стороне бизнеса, т.к. они деньги генерят.
Хорошо, что айтишникам это тоже понятно.
ET>Есть идеи как работать с такими персонажами?
Если внешний заказчик, то формализовать общение и выбивать деньги за каждую новую хотелку, если внутренний, то осознать, что задача программистов подносить снаряды и не выпендриваться. Нужно завести прослойку между вами и бизнесом (можно их бизнес-аналитиками обозвать, можно просто выделить человека, немного понимающего и в том, и в другом, можно даже двух человек, по одному с каждой стороны и еженедльные совещания между ними), выкатывать моки и бета-версии почаще, спрашивать и спрашивать побольше. Ситуация совершенно рабочая и указывает на недостаток общения между сторонами процесса разработки.

Здравствуйте, e.thrash, Вы писали:

ET>Есть идеи как работать с такими персонажами?

Составляете и согласовываете новое ТЗ, расписание и все остальное. Оговариваете что именно придется отложить чтобы реализовать срочную фичу.
Ну что-то забыли указать. Бывает. Что теперь в позу то вставать? Особенно когда вы — одна организация.

Здравствуйте, e.thrash, Вы писали:

ET>Часто бывает такое на работе.
ET>Есть заказчик со стороны бизнеса, который в момент составления ТЗ не пишет какие-то детали.
ET>После выполнения результата он что-то находит, что ему надо и что не указано в ТЗ.
ET>Тут у него начинается претензия "где кнопка Скачать в Иксель?"
ET>Ответ: в тз не было, сделаем через 2 недели, т.к. сейчас задачи идут по расписанию.
ET>и тут он начинает свою балалайку "это и так очевидно, у нас во всех юаях это есть"
ET>Иксель это как пример, в другом случае может быть фраза "без этого мы не можем работать"
ET>И потом начинаются письма директору, типа мы не можем чтото делать т.к. айти нам не сделало тото и тото.
ET>Понятно, что директор будет на стороне бизнеса, т.к. они деньги генерят.

ET>Есть идеи как работать с такими персонажами?

Заказчик внешний или внутренний?
Кого не устраивает такая ситуация, когда при сдаче ПО выявляются критичные недостатки? Есть ли у этих людей реальная власть?

Работать, имхо, можно только по одному сценарию — аджайл и плотная работа с заказчиком.

Здравствуйте, scf,

scf>Работать, имхо, можно только по одному сценарию — аджайл и плотная работа с заказчиком.

Вот тут я бы внес небольшое уточнение: "Работать, имхо, можно только по одному сценарию — <тут вставить название своей любимой технологии — хоть водопад, хоть скрам, хоть модный аджайл, хоть черт в ступе> и плотная работа с заказчиком."
Потому что если еще в первой итерации заказчик говорит: "Я имел в виду немного другое...", это лучше, чем если он это заявляет за день до выпуска релиза. Нет?

Здравствуйте, Masterspline, Вы писали:

M>А вообще, IMHO, единственный рабочий вариант общения с заказчиком — повременная оплата. Тогда будет пофиг на ТЗ и то, чего там нет. Ты платишь — я работаю, хочешь срочно — доплачивай.
Для обсуждаемых заказчиков такой подход как красная тряпка для быка.
https://youtu.be/gf8_sOlUBhg

Здравствуйте, Vlad_SP, Вы писали:

V_S>Вот тут я бы внес небольшое уточнение: "Работать, имхо, можно только по одному сценарию — <тут вставить название своей любимой технологии — хоть водопад, хоть скрам, хоть модный аджайл, хоть черт в ступе> и плотная работа с заказчиком."
V_S>Потому что если еще в первой итерации заказчик говорит: "Я имел в виду немного другое...", это лучше, чем если он это заявляет за день до выпуска релиза. Нет?

В идеале, заказчик должен иметь желание (!!!) и возможность видеть работающее приложение раз в неделю. А так называйте как угодно, да.

Здравствуйте, e.thrash, Вы писали:

ET>Есть идеи как работать с такими персонажами?

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

ET>Есть идеи как работать с такими персонажами?

Это не персонажи, это так устроен мир, постоянно что-то происходит и нужно учиться на это реагировать.
Например идешь на работу и тут жена звонит, ребенок заболел чем-то серьезным, надо срочно вызвать врача.
Т.е. появляется список задач
— дойти до работы
— вызвать врача

Ты один их можешь сделать или как-то распределить.
Т.е. это планирование и управление приоритетами.

В ответ на такие новости надо представить новые планы задач и сказать заказчику, выбирайте :
— + 5000$ фича 1 1 марта потом фича 2 1 апреля
— +10 000$ фича 1 1 марта фича 2 — 5 марта ( берем человека из резерва )
и т.д.

любой здравомыслящий человек знает
— машины времени нет, в прошлое нельзя вернуться и сделать иначе
— нельзя любое количество задач сделать за один и тот же промежуток времени, какие-то задачи придется пожертвовать или распаралелить , а каждая паралель стоит +1 человек.