Comments 50
У меня вопрос к автору по поводу фразы "Этого нет в ТЗ". На выход первой статьи я опоздал, потому задаю вопрос только сейчас.
Я тимлид, у меня фикспрайс проект с заранее составленным и оцененным ТЗ. В середине пути заказчик решает для себя, что у нас тут аджайл, и начинает просить бесконечных правок и отступлений от изначального ТЗ. Вопрос - если фраза "Этого нет в ТЗ" и все ее производные запрещены, то как следует себя вести по мнению автора в данной ситуации?
Вопрос - если фраза "Этого нет в ТЗ" и все ее производные запрещены, то как следует себя вести по мнению автора в данной ситуации?
Я не автор, но сам многократно бывал в подобной ситуации, и на своей шкуре в молодости проверил, что фраза "Этого нет в ТЗ" напрочь херит отношения со многими заказчиками. Правильный ответ: "Смотрите, для этого нам нужно будет сделать вот такие-то дополнительные работы, что вот так-то повлияет на стоимость и сроки". Вы в данном случае выступаете не как отказник, дескать, нам этого не задавали, мы не будем делать, а как проектировщик, который, собственно, принимает изменения, вносит их в проект и объясняет, как именно они повлияют на этот самый проект.
Только доказать порой, что очередная хотелка полностью уничтожает все выполненные работы и необходимо начинать всё сначала - очень сложно:
Вы же прошлую идею приняли в работу, а они ничем не отличаются!
напрочь херит отношения со многими заказчиками.
И правильно делает. Потому что такой заказчик - не заказчик. Он просто не туда попал, ведь этого не было в тз.
И правильно делает. Потому что такой заказчик - не заказчик
Очень легко так рассуждать, когда вы просто копаете отсюда и до вечера, и вам за это капает зарплата на карту. А всякие бизнесовые вопросы решает кто-то другой, и вам совершенно пофигу, каким образом и благодаря каким людям эта самая зарплата попадает к вам.
Менеджер по обуванию клиента видит только свой процент от копеечки, которую тот заплатит и не вникает в суть проблемы - "похоже на то, что мы делали стотыщраз, значит берём в работу". А что-то большее требует от него непомерных усилий и навыков, которые не проверяли, беря его на работу. То есть минимальный уровень по тех-части и минимальное же внимание к деталям в плане умения понять, что действительно нужно заказчику, а если тот сам не в курсе, то правильно задать вопросы для прояснения ситуации.
Я не понимаю, чем вы недовольны. У вас ведь замечательную команду можно собрать: заказчик, который не туда попал, менеджер по обуванию клиента, и ещё осталось найти разработчика, работающего "на отвали", это также несложно, так и пишите в вакансии. Собирайтесь, делайте стартап-единорог (с блокчейном уже не получится, но можно ещё ИИ-проект успеть) и радуйтесь жизни :)
Этого нет в тз, само по себе не является запретной фразой. И сильно зависит от контекста.
Если сказать "этого не было в ТЗ." подразумевая иди куда подальше, то да, такое себе.
А вот если "Этого не было в ТЗ, но мы готовы рассмотреть ваше предложение, однако это бла бла бла." звучит нормально, это не отказ, + сразу предлагаем возможные действия.
А вы по ссылке прошли, статью прочитали? Потому что она дает ответ именно на этот вопрос. А на комментарии и вопросы я там подробнейше ответил в каментах. Если есть вопрос про ТЗ - пишите туда, я тоже отвечу :)
Что делать - ясно там, это классика качественного управления.
Да и у меня статья есть "как говорить НЕТ, когда все хотят слышать ДА". Она тут на сайте - там все ответы, исчерпывающе
Я прошел и прочитал. Там предложены варианты сказать "давайте попробуем прикинуть, в каком бюджете мы будем это делать". Заказчики, с которыми мне приходилось работать, на такие ответы сразу же говорят "ну как в каком бюджете, в уже согласованном, мы же заплатили". Потому я и хотел бы уточнить у вас как у эксперта в данной области, как стоит строить диалог в данном случае
Вы слишком сложные вопросы автору задаете. Их не было в ТЗ на статью ))
на такие ответы сразу же говорят "ну как в каком бюджете, в уже согласованном, мы же заплатили".
Я опять же таки, могу поделиться своим опытом. Абзац в договоре: "Изменения в техническом задании, не увеличивающие сроки и/или стоимость работ, согласовываются в рабочем порядке. Изменения в техническом задании, увеличивающие сроки и/или стоимость работ, оформляются в виде дополнительного соглашения к текущему договору." принимается заказчиков практически в 100% случаев. По крайней мере, у меня вообще не было ни одного кейса, когда заказчика это не устроило. Но если у вас такого нет, то вы точно так же можете ответить, что тот бюджет мы согласовали для перечня работ, описанных в ТЗ, данная доработка выходит за рамки оговоренного, поэтому давайте её оформим отдельно, либо, если у вас есть сложность в изменении бюджета (а такое тоже в порядке вещей в В2В), давайте с вами решим, какой второстепенный функционал из ТЗ мы уберём или перенесём на следующую фазу, чтобы остаться в текущем бюджете.
вы точно так же можете ответить, что тот бюджет мы согласовали для перечня работ, описанных в ТЗ, данная доработка выходит за рамки оговоренного, поэтому давайте её оформим отдельно
Ну то есть сказать "этого нет в ТЗ", но другими словами. Все как я и думал, чудес не бывает, спасибо за ответы
Ну то есть сказать "этого нет в ТЗ", но другими словами.
Тут ключевой момент именно в продолжении фразы. Просто в чистом виде "этого нет в ТЗ" означает "я не буду этого делать" :) А фраза "Я буду это делать, но мне надо больше денег и времени", это как раз нормально. Ваш заказчик точно так же говорит своим клиентам, когда они у него заказывают дополнительные услуги или дополнительную партию товара.
не факт. в простых случаях прокатит. в сложных - вы будете втянуты в спор с заказчиком на тему, кто дурак: толи ваши аналитики, которые продолбали требования, толи бизнес. И по опыту, послушают скорее бизнес, только если у вас не будет железобетонной базы в виде протоколов именно в нужных формулировках.
Что бывает, но нечасто, потому что если вы практикующий РП вы знаете, что все зафиксировать невозможно, а если вы попробуете - этого читать никто не будет.
Поэтому фраза "Этого нет в ТЗ, но мы добавим за деньги" - тоже не очень приближает вас к результату.
Есть много других фраз вообще вбок, которые реально помогают.
самая простая: а что это и зачем нужно? Почему это критично, как вы считаете? а почему на этапе сбора требований это мы не обсудили (уже веет, но аккуратно).
Отдельно - есть способ взять в объем небольшую доработку, пойдя заказчику на встречу. и еще есть, но не могу же я переписать всю статью заново в камент. Тем более что после нее я еще 2 дописал в тележке.
самая простая: а что это и зачем нужно? Почему это критично, как вы считаете?
Да, верно. Я просто рассуждаю, полагая, что этот момент уже пройден и пришли к выводу, что делать это таки нужно, и оно стоит каких-то существенных денег, выбивающихся из заложенного бюджета. Если было бы не обязательно или банально недорого, разговор получился бы намного проще.
угу. Если у вас такое ТЗ, что заказчик и правда за все заплатил, и вы сами лично его согласовали - придется сделать. Это раз.
Если серая зона - это отличный повод для договоренностей. Про это я пишу на канале, есть несколько стратегий. Если вам реально интересно, и в не просто тролите, могу дать пару ссылок на канал, маякните.
Если коротко 1: для неопределенности должен быть небольшой буфер (или большой, зависит от рисков), если нет ни буфера, ни требований а вы согласились - вопрос к вам - нафига?
Если коротко 2: часто можно договориться на небольшие и реально критичные доработки, а по остальным вступить в дискуссию "а зачем это нужно, давайте обсудим". Как правило, только если проект не провален в части аналитики, реально критичного упускается мало.
Ну, и отвечая именно на ваш кейс:
Я тимлид, у меня фикспрайс проект с заранее составленным и оцененным ТЗ. В середине пути заказчик решает для себя, что у нас тут аджайл, и начинает просить бесконечных правок и отступлений от изначального ТЗ. Вопрос - если фраза "Этого нет в ТЗ" и все ее производные запрещены, то как следует себя вести по мнению автора в данной ситуации
Заказчик , как правило, не решает аджайл или нет. Ему вообще плевать на методологию. Ему надо добавить требования в объем которые по какой то причине были пропущены.
Или ИТ команда профакапила анализ (что бывает), или бизнес пропустил (бывает также). А дальше у меня вопрос: насколько этап 1 встанет без этих доработок? Что на них завязано и какая цена вопроса? Если критично и недорого - можно и пойти на встречу. Если некритично - можно сделать потом (тем более, что сейчас уже работы идут и их изменние приведет к изменению сроков).
А может быть надо собраться, все систематизировать и сделать Этап 2 проекта.
Итак: я предложил несколько вариантов решения на ваш кейс и ни разу не ответил "Этого нет в ТЗ".
Ответил?
Не ответил. Я пока слышу только "ну должно было быть учтено на старте то и это". Серая зона есть вообще всегда, в любых требованиях, даже в самом жестко составленном ТЗ. Абсолютно каждую самую мелкую лазейку на старте не обсудишь. Отсюда и возникают все эти разговоры "а давайте сделаем вот это вот в рамках уже согласованного бюджета", иначе бы даже проблемы такой не было. Здесь кнопку перекрасим, там +1 мелкое вычисление добавим, и все это бесконечно. По практике, до определенного момента идешь на эти компромиссы в рамках поддержания хороших отношений с заказчиком, но если заказчики начинают наглеть, никакого другого варианта, кроме как проявлять определенную жесткость, не остается и волшебной таблетки не существует, что, собственно, ваши слова сейчас и подтверждают. Спасибо за ответы
Абсолютно каждую самую мелкую лазейку на старте не обсудишь.
Нет, но помимо собственно работ, в бюджет сразу надо заложить и свои риски, в том числе и на какие-то мелкие вычисления/перекраски кнопок.
И да и нет. Все риски подряд заложить невозможно, да и если попытаться, то цена будет такой, что никто не законтрактуется. Потому всегда ищешь баланс и к ситуациям, где нужно остаивать свои интересы, нужно быть готовым. Есть вообще люди, которые мягкого и дипломатичного языка не понимают, если что, и переговоры ведут в буквально быдло стиле. К сожалению, такое тоже имеет место быть в далеко не маленьких компаниях, и в этом случае тем более все эти советы про "сказать нет не говоря нет" будут тупо восприняты как слабость
в быдло стиле на "этого нет в ТЗ" обычно отвечают (и такое я тоже встречал): "потому что твои аналитики криворукие дебилы и написали говно, я за это платить не собираюсь и мне вообще плевать как ты это решишь" А дальше это летит шефу, для которого данный клиент важный и любимый.
И конечно можно уволиться, но можно и договориться, просто не надо лезть на рожон в слабой позиции.
Оттенки очень важны. Наверное корень в том же самом, что и по всем остальным фразам: запрещенная фраза просто констатирует факт, и менеджер не предлагает решения проблемы заказчика.
Заказчику это, как правило, не нравится.
Ну и отдельно именно "Этого нет в ТЗ" моментально и всегда (всегда) приводит к выяснению точно что там есть и нет и попыткам найти его недостатки. И почти всегда они там есть.
А инструменты, да, такие:
брать мелочевку и делать не просто молча типа "ну ок", нет, каждый раз подчеркивая, как мы идем на встречу выполняя допработу. Ночами не спим. Три раза придет, на четвертый уже можно эскалировать шефу: мы им идем на встречу, давайте прекратим - бюджет нерезиновый. Это вообще иная позиция.
не делать вообще, сперва задаваясь вопросом: "а кому это вообще надо и для чего?" Очень часто многие CR умирают именно в этом месте
не делать вообще, задавая вопросы по технике, на которые бизнес ответить просто не в силах. И тогда реализация переезжает в следующую фазу автоматом: у нас же сроки, мы не можем сдать.
Ну и уж точно не говори «я не помню». Если это твой проект, а ты не в контексте – это залет, а если проект не твой – так и говори.
То есть если реально что-то забыл, надо врать? Да и что это такое за клейм: "залёт"? Типа ошибаться не по пацански? Мы тут серьёзные люди, не можем ничего забыть? Это как-то несерьёзно.
У вас статья написана с позиции что разработчик должен создавать образ себя в глазах заказчика/руководителя. А это значит, что он должен тратить свой ресурс на враньё, перекладывание ответственности и отмазки. Так вот: это не так.
То есть если реально что-то забыл, надо врать?
А тут не надо врать. В чистом виде "я не помню", это форма отказа дать информацию. Типа "я не знаю, и на этом точка". Даже банально "я не помню, надо посмотреть, тогда отвечу" - это абсолютно нормальный ответ.
У вас статья написана с позиции что разработчик должен создавать образ себя в глазах заказчика/руководителя.
Статья называется "памятка менеджеру", а не "памятка разработчику" ведь :)
А это значит, что он должен тратить свой ресурс на враньё, перекладывание ответственности и отмазки.
Ну, в корпоративной борьбе этого предостаточно. И собственно, скажите спасибо менеджерам, что этим занимаются они, а не заставляют нырять в сие г...но разработчиков.
ну вам коллега все ответил уже, все так: я не помню - это просто фраза которая говорит "я ничего делать не буду". Это плохая позиция для менеджера. Да и для исполнителя тоже, если он отвечает по задаче. Да еще и показывает нежелание помогать.
А так как мы про менеджеров, то кому он так может ответить? Заказчику или шефу (тоже заказчику). Отлично, выходит, вы не хотите помогать тем, кто вам деньги платит?
Менеджер - не секретарша и не аниматор. Его задача - чтобы проекты (все, а не только один конкретный) двигались, команда работала и сроки не срывались. Если менеджер хорошо делает свою работу, то пусть шеф смирится. А заказчик подумает, как так вышло, что хороший менеджер отказывается выполнять поставленную задачу.
А если работает плохо, то все эти трюки, рано или поздно, дааут сбой, и отмазаться не выйдет.
Если менеджер хорошо делает свою работу, то пусть шеф смирится.
Менеджер - это ещё и не лошадь. Любой менеджер работает свою работу по-разному, сегодня хорошо, завтра плохо, послезавтра снова хорошо. А все команды, даже самые лучшие, могут ругаться и внутри себя, и с другими командами, могут срывать сроки и по объективным, и по субъективным причинам. Компания, это общество, там всегда будут какие-то конфликты, споры, конкуренция, дипломатия и войны. Это данность, это никак не зависит от качества вашей работы. И их всегда приходится разруливать руководителям разных уровней.
Его задача - чтобы проекты (все, а не только один конкретный) двигались, команда работала и сроки не срывались
Замечательно.
А если он делает проекты хорошо, но заказчик не доволен и не дает новых проектов? А если от него команда разбегается? А что если даже заказчик доволен, а недоволен шеф (который и есть главный заказчик менеджера, кстати)? Шефа послать нахрен?
Уточните, пожалуйста
А если он делает проекты хорошо, но заказчик не доволен и не дает новых проектов?
Менять место работы, и чем быстрее - тем лучше.
Шефа послать нахрен?
Иногда без этого никак. Лучше совместить с прошлым советом.
Ваша логика нормально работает для исполнителя по задаче. От РП требуется смотреть несколько дальше, чем 1 задача или 1 проект. Есть классический вопрос на собеседовании РП "что такое успешный проект?"
Так вот успешный - это не только сделанный в срок и бюджет. Если проект сделан хорошо, но отношения испорчены, это почти всегда неуспешный проект.
Ну и конечно же я не призываю нигде молча соглашаться со всем, что менеджеру предлагают, я пишу о другом. Есть 100 и 1 способ говорить иначе. Это просто навык переговоров и умение отстаивать личные и профессиональные границы, не теряя способности договариваться.
Уважаемый автор, вы совершили одну и ту же ошибку целых три раза - в каждой из трёх частей, даже не вспомнили о знаменитом "мы вас услышали!". А то, о чём вы пишете, и то, как вы это пишете, напоминает мне mp3 с записью какого-то "экстрасенса" из 90х, который, сначала просто громко "е*ться стыдно, е*ться стыдно!", а потом как заорёт "НЕ ПЕЕЕЙ!!!".
Вся эта мнимая клиентоориентированность - она, ни яйца ломанного, ни гроша выеденного, не стоит. Поэтому не нужно ни чего выписывать, в этом плане, ни на какие бумажки.
(Уровень конструктивности первой части данного комментария, на всякий случай, редуцирован до уровня посыла всех трёх частей)
А теперь по делу: единственный здравый момент из всех трёх частей, которые, очистив от шума, можно сократить до одной фразы - "необходимо письменное протоколирование всего и вся, в виде официальных документов - за подписями сторон, естественно." Точка, конец предложения.
Плюсовать не могу, напишу здесь.
необходимо письменное протоколирование всего и вся, в виде официальных документов - за подписями сторон, естественно.
Да, именно так. А ещё без всякого "стеснения" писать все разговоры, с вышестоящим руководством, заказчиком, смежниками и т.п., на всех каналах связи, которые используются для коммуникаций. А так же, не без всякого "стеснения" выкладывать это всё в виде аргументов на стол, когда идёт разбор полётов.
Блин, факт, Я ВАС УСЛЫШАЛ забыл ( вот что значит, писать статьи по ночам. а в Телеге, кстати, мы мощно перетерли и ее (заходите в мой канал и вы, дада, ссылочки под роликом, как водится), и знаете что? 1/3 подписчиков воспринимает ее совершенно нормально. Я бы сказал, что она мерзкая, но сильно не вредит, так что в списке она лишняя. У меня только максимально вредительские.
Чтобы нам с вами поговорить про клиентоориентированность и чего она стоит, мне надо понять ваш опыт: если вы продаван и знаете другие способы win-win кроме как понимать потребности вашего клиента и удовлетворять их - поделитесь, пожалуйста. Про себя и свой опыт я в профиле написал много, у вас в профиле ничего нет. А с дивана критиковать можно, но смысл.
Протоколировать надо, да. Но не только это. Менеджер который только протоколирует - это тупой админ.
Формально, может и не вредит, но показывает реальное отношение собеседника к проблеме. А такое отношение может нанести обиды и даже моральный вред.
Почти всегда работал программистом, но был такой опыт - миллион продажников впаривает что-то там, подо что делается много мелких и не очень мелких задач на моей стороне, и вот на этой работе всякое повидал и во всяком поучаствовал, из того, что никак не касалось моих прямых обязанностей. То есть приходилось переделывать то, что поленились сделать менеджеры, включая прямое общение с заказчиком. Вынужден был заставлять менеджеров, формально находившихся надо мной, выполнять их же собственные регламенты. Переписка внутри компании, в которой я тогда работал, шла по электронной почте или в трекере задач, поэтому руководство всегда стояло в копии. Не сказал бы, чтобы это хоть как-нибудь дисциплинировало менеджерию, зато с меня всех собак снимало (тз согласованно с учетом особенностей платформы, проект выполнен в срок, всё задокументировано, протестировано и сдано, куда надо).
Для начала, надо научить менеджера читать регламенты, за выполнение которых он расписывается, а это уже не только протоколирование. Постепенно и до аккуратного выполнения прямых обязанностей доберется. ;)
Формально, может и не вредит, но показывает реальное отношение собеседника к проблеме. А такое отношение может нанести обиды и даже моральный вред.
Запросто. Но "я вас услышал", это скорее инструмент отстаивания границ. С делового на русский переводится как "вы мне уже пять раз этого говорили, отвалите наконец, пожалуйста". В некоторых случаях вполне уместно.
но был такой опыт - миллион продажников впаривает что-то там, подо что делается много мелких и не очень мелких задач на моей стороне
Похоже на 1С, если так, понимаю ваш негатив, работа в некоторых франчах 1С порой оставляет травмы на всю жизнь
да ладно вам. отстойная пассивно-агрессивная фраза. https://t.me/morkovka_speredi_morkovka_szadi/271 вот тут в каменты загляните (не реклама, просто там хорошо обсудили), если хотите. Тут уже не буду писать, извините, не успеваю :)
Но "я вас услышал", это скорее инструмент отстаивания границ. С делового на русский переводится как "вы мне уже пять раз этого говорили, отвалите наконец, пожалуйста". В некоторых случаях вполне уместно.
Часто приходится слышать "это", когда мне впервые задали вопрос, я дал конкретный и четкий ответ, в сжатой форме. Но, вместо ожидаемых вопросов - "да, мы вас услышали". Ну хорошо, я очень рад, конечно.
Похоже на 1С, если так, понимаю ваш негатив, работа в некоторых франчах 1С порой оставляет травмы на всю жизнь
Не обязательно 1С. Мелочёвка разная бывает и она по-разному мелка. Порою, то, что я тут назвал мелочёвкой, могут обозвать крупным проектом. Спасибо, хоть не федеральным. А по факту - ерунда.
Понял вас. С позиции разработчика, который вынужден брать на себя работу непрофессиональных менеджеров, которые неспособны ограничить объем и защитить команду от треша, вы 100% правы.
Задача менеджера (тоже много писал про это) видится мне в том, что для клиента он должен быть удовлетворителем потребностей, но не за счет команды и не за счет своей компании, в целом. Это непросто и это как раз показатель профессионализма, софтскиллов и всего о чем я пишу. Но чтобы разом ответить на все, нужна книжка (может и издам по мотивам статей потом). А тут просто статья, чего говорить им нельзя.
Потому что менеджер - штука нежная: ему говоришь "не ложись под заказчика" и он начинает всех слать, а потом проектов нет. Говоришь ему "будь добрее" - он подписывается вообще подо всем. Вот и приходится учить балансу :)
Для команды менеджер должен быть требовательным помощником. Тогда отлично работает связка: он прикрывает пацанов, а пацаны - его. Я так работал, и по моему, это самый лучший формат.
Про регламенты тоже писал, и там баланс знать надо. Есть менеджеры, которые даже в CV не стесняются написать, что они создали несколько сотен регламентов за год работы (!) Оно то конечно наверное круто и эффективно, только такое на практике никто не читает :) А так то согласен.
Если это твой проект — должен знать, а если не твой — так и говори.
Моя хата с краю, я ничего не знаю!
А если серьезно, то рекомендация работает редко и не во всех компаниях, если уж речь идет о менеджере.
Правильнее будет: Если это твой проект — должен знать, иначе говори я выяснию и отвечу или направлю к человеку который владеет информацией.
Памятка менеджеру: запрещённые фразы в IT. Часть 3, финальная