Comments 48
"Этого нет в ТЗ и проверка ТЗ не входит в мою должностную инструкцию"
Только хардкор!
А еще фраза ЭТОГО НЕТ В ТЗ может побудить других начать искать ошибки уже в вашей работе (ну а как иначе – иначе вы получаетесь в слишком белом пальто).
Так и пусть ищут. Я не знаю, как там у менеджеров, но у разработчиков хаос прекратился только когда стали разными способами искать ошибки у себя и у других. Тесты, сканирования, ревью и т.д.
у разработчиков - это хорошая и работая фраза. У манагеров - нет нет и нет
Только часто манагер приходит с этим к своим разрабам, а не к клиенту и получает ровно такой же ответ, но при этом своих легко давить чем клиента, если что можно и в выходные народ вывести. А в итоге выводы не сделаны, и в следующем проекте все повтряется.
увы, все так. причем, я вижу что у нас на рынке в РФ таких тенденций больше и больше: вместо того, чтобы учиться говорить "нет", манагеры учатся манипулировать командой. Потому и начал писать статьи год назад.
Но, кстати, в бигтехах массово наблюдаю противоположную картину: разработчики берут дикие сроки на ерунду (кнопку добавить - неделя), манагеры такие "ой я не буду спорить, лишь бы сделал". И в итоге компания тратит зазря огромные бабки на ФОТ бездельников - разработчиков.
Я бы сказал - все хороши уже :)
По сути написано верно, но...
Касаемо фразы "ЭТОГО НЕТ В МОЕЙ ДОЛЖНОСТНОЙ ИНСТРУКЦИИ!". Если на все ваши другие аргументы 1,2,3 (они перечислены в статье) вы получаете ответы в стиле "Я начальник - ты дурак. Клиент за это платит." - значит пора уходить. Правда в ситуации если вы реально специалист, а не просто "думаете что вы специалист"...
ТЗ оно на то и ТЗ
Составляется, и подтверждается... Потом вдруг заказчик захочет, чтоб приложение и ракеты в космос запускали
Должностная инструкция, тоже имеет юридическое основание. А так директор может сказать, Петя мне там фура кирпичей приехала на дачу, надо разгрузить...
статья как раз о том, что имея совершенно твердое юридическое обоснование, можно как испортить отношения с людьми, так и сохранить их (или приумножить в контексте зарабатываемых денег). И что для этого надо делать.
А уж дальше товарищ менеджер пусть сам выбирает таблетку: красную или синюю.
И еще раз: это касается именно менеджеров и их софтскилов. Это НЕ касается ИТ исполнителей. Тут как раз надо четко границы отслеживать.
Выкручиваться - менеджерское дело, ему за это деньги платят (а не просто за то что он по Ганту колбаски гоняет)
Вот тут категорически не согласен.
Отношения, штука, безусловно важная. Пока кому-то из участников не прижмет хвост. И как только что-то пошло не так с вашей стороны ни один адекватный заказчик не лишит себя привилегии "потыкать носом Вас и команду в то, что не реализовано то, что ЕСТЬ В ТЗ".
Задача любого начальника/заказчика/руководителя/менеджера не просто поставить задачу, а убедиться, что его поняли именно так, как он это представлял. И как раз ТЗ должно являться фиксацией того самого общего видения, которое сходится у заказчика и исполнителя. И как в таком случае, по мнению автора, сожно разделить банальное непонимание/неопытность/некомпетентность заказчика, который забыл указать какое-то, по его мнению не важное, уточнение (неважным оно ему кажется именно из-за не опытности) от намеренного искажения с целью снижения цены. Ведь в случае, например, большого проекта с частичной предоплатой, на поздних этапах из-за кассового разрыва исполнитель буквально становится заложником заказчика, т.к. он то на людей уже потратился. Если не полная предоплата - это вилы, тобой и с ТЗ крутят как угодно.
"Хороший человек - не профессия" и "Вежливость -главное орудие вора" - эти две народные мудрости глубже, чем кажется. Именно под маской отношений вытягиваю скидки, снижают цену, продавливаю допы. В любой трактовке - жто тот же сценарий win-loose, только в этом случае заказчик пытается выиграть больше за счет исполнителя. Не забывайте, вы делите ограниченный пирог, чем больше "отожмет" заказчик, тем меньше достанется исполнителю.
А что делать, если у вас есть "субчики" или просто другие команды, которые участвуют в реализации того же проекта? Ведь если НЕТ В ТЗ у Вас, соответственно и у них НЕТ В ТЗ. а тут возвращаемся к п.1. Составление ТЗ - это общая ответственность заказчика и исполнителя. Теперь просто подумайте, в описанной ситуации как вы будете с субподрядчиком общаться на тему доп.работ? Тоже без доп.оплаты? Они ж тоже, получается, недоисследовали/недопоняли/недодумали/не угадали. Или из своей компании вынете ресурс?
Я не хочу сказать, что нужно всех и каждого по матери за каждый косяк. Но что касается коммуникаций - поиск четкого взаимопонимания - это обоюдная задача. И, если заказчик хочет получить ожидаемый результат, у него нет иного пути, кроме детального погружения во все аспекты и контроля на всех этапах. И первый из них - убедиться а правильно ли его запрос поняли.
А я даже спорить не буду, вы совершенно, просто на 150% правы. Договоренности должны быть.
Моя позиция всегда постоянна, все мои статьи на Хабре почти про одно и тоже: "добрым словом и пистолетом можно сделать намного больше, чем просто добрым словом", только я ее немного переворачиваю: "пистолетом и добрым словом можно сделать намного больше, чем просто пистолетом".
Пистолет = ТЗ
Доброе слово = хорошие отношение и желание помочь.
Желание "отжать" есть всегда и это норм. При этом и теория - игр, я не скажу что очень умный, но базовые стратегии и их ограничения понимаю - и практика моя лично, показывают, что выгоднее договариваться.
Да, когда прижмет, ты можешь стать крайним. Да, я участвовал в проектах, когда заказчик тупо использовал и кидал исполнителя - бывает, риски. А все равно фраза "Этого нет в ТЗ" никогда не помогала отношениям.
Это не значит , что нельзя заказчику говорить "нет", еще как можно. Просто не так топорно и в лоб. А вот как - я отдельно писал, есть статья "как говорить "нет", когда все от вас ждут "да"".
БЕЗ ТЗ РЕЗУЛЬТАТ ЗХ
Тут надо понимать, какой Абра-Кадабра вопрос вызвал "ЭТОГО НЕТ В МОЕЙ ДОЛЖНОСТНОЙ ИНСТРУКЦИИ!". Одно дело, что кто-то забыл в должностную программиста прописать написание кода по ТЗ, и другое, когда это вообще левые обязанности. Например, на прошлой работе, когда нужно было после уборки территории грузить лопатами снег в камазы, начальство быстро находило самых недогруженных бездельников, которые, как никто, подходили для этого: инженеры! А однажды завёлся в команде настоящий буйный, возьми, да и спроси. И оказалось, что ничего страшного, просто машины для вывоза снега стали приходить со специально обученными людьми. И даже не уволили никого.
1)Нужно всё зарегулировать. Регулирование зарегулирования тоже надо урегулировать. Массив должен быть в объеме непосильным для осознания и применения. Чтоб никто концев не нашёл.
2) Всё, что просят сделать - надо делать, бесплатно, сразу и безоговорочно. За лояльность. Чтоб потом было что ещё поделать бесплатно.
3) Все, что сделано не по ТЗ и инструкции обязательно должно сломать, что сделано по ТЗ и Инструкции. Иначе, как заказчик избежит ответственности и сможет дать в будущем новый заказ.
Итого: лояльность важней денег, времени, профессионализма. Именна она даёт новую работу.
Ничего не напоминает?
Вообще не по статье камент
Вы знаете, не напоминает. Если у вас перед глазами есть какой-то пример - поделитесь примером. Я не понимаю, каким образом ваши тезисы относятся к моей статье:
я не писал про зарегулированность
я не писал про то, что надо делать все, что просят
я не писал про то что лояльность важнее денег и времени.
Уточните, если вам нужен ответ, наводящие вопросы, это хорошо, но привяжите к контексту.
Да, договорами занимаются юристы, финансами — бухгалтеры, а доставку выполняют курьеры. Но жизнь непредсказуема: курьеров может не быть, платёж может быть критически важен, и помочь попросят именно вас. Ваше желание помочь вашему главному заказчику — вашему шефу — это крайне важный фактор вашего роста. Если желания помогать у вас нет — нафиг вас растить (да и вообще нафиг вы нужны, ведь в критической ситуации рассчитывать на вас нельзя)?
Вот именно, что жизнь непредсказуема. Задача менеджеров управлять так, чтобы хаоса не было, а подход в стиле: "нам нужно что-то срочное за 2 - 3 часа", работает плохо и отъедает время от других задач, которые делаются с таким же плохим результатом.
И вот зачем тогда менеджер, который не может отстаивать интересы команды, а просто перепоручать разную не относящую к специалисту деятельность?
Автору на заметку из личной практики.
2019 год, сдаю заказчику (муниципалитет) концессионный проект по автоматизации некоторого процесса в части административного делопроизводства. И в рамках проекта необходимо было интегрировать разработанную систему с системами МВД. А мы работаем от муниципалитета. Для не погруженных - муниципалитет не может решать серьезные вопросы с министерством, только субъект.
И так вышло, что в рамках проекта субъект нам поддержку в диалоге с МВД не оказал. Разумеется, будучи коммерческой компанией, от лица муниципалитета с системами МВД нам никто не разрешил интегрироваться.
Но, ТЗ на нашу систему содержало фразу: "...при наличии технической и организационной возможности необходимо...". Организационную так и не подвезли, 11 регламентов взаимодействия нам завернули.
Идем сдаваться, демонстрируем все, а на месте интеграции - ручное заполнение (в формате официальных запросов на бумаге делопроизводство уже работало). Разумеется, заказчик недоволен. После длительного спора с ним апелирую к тому, что ЕСТЬ В ТЗ, получаю короткий ответ: "Я это ТЗ составлял, здесь этого быть не может, здесь этого нет." (В этот момент перед ним лежит открытый на нужной странице экземпляр концессии, подписанный живыми подписями главы города и прочих уполномоченных лиц). Занавес.
При этом мы им и дизайн несколько раз за свой счет меняли, чтоб соответствовал айдентике города, и дополнительные формы, сделали, чтоб удобнее, и кучу обучений провели, на связи были по любым вопросам, консультаций и т.п. (всего этого в ТЗ не было) как итог, вместо маржи в 7% на реализацию мы в минусе на 17М только в капекс проекта. Еще и с кассовым разрывом в 120М и перспективой суда, т.к. заказчик не хочет принимать по своему же ТЗ.
Мораль простая - там где деньги - человеческие отношения - это лишь инструмент манипуляций, не более того. Лучше научитесь разделять отношения и работу. Хорошими личными качествами профессионализм не заменить. (Верно и обратноное). Как известно, война - это продолжение дипломатии, и в этом контексте "ЭТО НЕТ В СОГОСОВАННОМ ТЗ" - это превосходный оберег от попыток продавить Вашу команду. Просто использовать каждый инструмент нужно правильно и своевременно. Но, однозначно, стигматизация этой фразы - это очень странно.
PS: проект сдали но через "человеческие отношения" с более уполномоченными людьми, т.к. всем было ясно, что суд мы выиграем и репутацию всем подмочим. Да и банкротить нас никому выгоды не было.
Спасибо. Я сам сталкивался с подобными ситуациями.
Скажите пожалуйста, в вашем примере фраза "Этого нет в ТЗ" приблизила вас к сдаче проекта?
В моем примере сам заказчик, проигнорировал лояльность со стороны исполнителя и сотни человекочасов бесплатных работ сверх ТЗ, и начал выкручивать руки, когда мы воспользовались лазейкой, которая в этом ТЗ есть. Так что в данном случае нас приблизила к сдаче готовность защищать себя в суде, на основании того что в ТЗ ЕСТЬ а учитывая, что это концессия с госзаказчиком, точно еще и прокуратура подключилась бы. Так что это был тот самый момент, когда мы жертвуя "отношениями" пошли на осознанный конфликт и защитили свою компанию.
Спасибо, понял.
В вопросе отношений с заказчиком нет непреложной истины и волшебной таблетки для меня, есть только устойчивые паттерны, которые повторяются.
В статье речь идет про отказ от негативной фразы в общем случае. Вы привели исключение - угрозу судебных разбирательств. Уверен, что если вы делали много проектов, у вас таких случаев немного.
Почему уверен: потому что и в моем опыте и в опыте многих коллег я слышу одно и тоже (да и теория игр говорит аналогичное): win-win выгоднее для обеих сторон. А поэтому выгоднее договариваться.
Это не отменяет жесткости позиции, но, мой тезис в другом: позиция должна быть доброжелательной. Разумеется, пока одна из сторон не собралась в суд.
Но судами заканчивается очень мало проектов, так что я бы назвал это исключением. Поделитесь, если в вашем опыте иначе (из скольки запущенных проектов у вас сколько закончилось судами или околосудебными разборками).
Искренне интересно, так как у меня за 50-100 проектов (я точно не считал, но оч много) - ни одного. Да, собирались в суд несколько раз, но всегда договаривались. И да, фраза "нет в ТЗ" работала плохо, договаривались "по понятиям", как и в вашем случае.
На проектах стлимостью в пару-тройку млн, действительно легко договариваться и улыбаться. Даже на десятке-другом все достаточно прозрачно и обозримо. Протерять что-то в ТЗ на таком объеме только по лютоиу раззвездяйству можно. Но в тех, что переваливали за сотню капекс - досудебные разбирательства и суды - обычное дело (7 из 12). Ключевая сложность: если цена переваливает до 100М крайне маловероятно, что все будет выполняться одним заказчиком. Наиболее вероятно - это 1 ген.подрядчик и каскад субчиков. И вот тут и начинается самое интересное: неучтенные требования от одного - это минус в марже другого. А сколько звеньев в цепочке субчиков едва ли кто-то ответит.
Я не рассматриваю внутренние проекты в рамках разных департаментов - тут как ни крути - оплата из одного кармана, а там где нет дележки прибыли - там особо и бадаться не за что. Если в такой ситуации люди (а тем более менеджеры) не могут договориться - это уже не проблема менеджмента, а, скорее, подбора, и решать её нужно соответствующим образом.
Но, понятие проектного менеджмента подразумевает унификацию и любой менеджер обязан уметь работать со всем возможным инструментарием для достижения своих целей: подкуп, шантаж и угрозы (если вдуматься, все к этому и сводится, просто названия более толерантные придумали). И вся моя критика направлена именно на стигматизацию более жесткого отстаивания своих позиций. Неопытного менеджера подобная рекомендация банально обезаружит.
Как уже писал - война - это продолжение дипломатии, не более того. Так же и фраза "НЕТ В ТЗ" - это один из аргументов, абсолютно легитимный и разумный, и в правильной ситуации он может помочь избавиться от десятков часов пустых коммуникаций. А напомню, задача менеджера не просто управлять, а делать жто эффективно. А эффективност, как известно, это частное от результата и затрат (в т.ч. на коммуникации, споры и дипломатию).
продолжим давайте) 100М рублей или других условных единиц?
Я и за ярд проекты делал, неоднократно. Не было судов. Крики, шум, пыль - да. А судов нет. Больше того, почти всегда (исключение - лютая политика) мои аккаунты росли YoY на 20% (ну это примерно за последние лет 15, бывало и веселее). Я считаю, именно за счет желания помогать и умения договориться с клиентом. Да, иногда делали виноватым, иногда помогал проектный запас на это все.
Если вы про проекты более 1 млрд и цепочки субчиков - пожалуй, соглашусь - там вообще другая коммуникация. Матрица ответственности, борда стейкхолдеров и уведомления под роспись, чтобы никто не отполз. Тут готов сказать, что я пишу обо всем, что менее ярда на рынке ИТ РФ. и таких проектов (в штуках) - подавляющее большинство. Пусть начинающие менеджеры сперва учатся азам: сперва надо догвариваться и только потом идти бить друг другу лица. Война - продолжение политики. Но для меня - именно продолжение. Сперва - политика )
Правильно, но ведь статья называется не "порядок эскалации конфликта", и не "политические аспекты ведения переговоров". Вы сами выбрали "запретный" посыл. И критика именно об этом. Повторю, я не призываю с первой встречи возить по столу любого контрагента, но и избегать каждого конфликта это не выход.
"Добрым словом и пистолетом вы можете добиться гораздо большего, чем одним только добрым словом" (с)
Довольно размытая статья, описывающая исполнителя как существо бестелесное и бесправное, а заказчика - как бога, царя и властелина.
Не утверждаю того, что всё должно быть наоборот, просто все эти нюансы и аспекты лучше заранее прописывать в договоре, с указанием чёткого количества мелких правок, входящих в стоимость проекта (всё что сверху - оплачивается отдельно в рамках допников). И каждый средний либо большой проект разбивается на этапы с разбивкой оплаты за каждый выполненный этап, который закрывается актом выполненных работ с подписью заказчика. Ошибся заказчик? Что-то проморгал и не написал в ТЗ, и на каком-то этапе работа встала? Случается, с кем не бывает, все мы люди. Составляется дополнительное соглашение к договору с заранее оговоренной ценой, которое так же закрывается актом выполненных работ - и вперёд.
Во-первых это спасёт добросовестного исполнителя (при условии его чёткого следования техзаданию) от "рабства" у заказчика, у которого может быть 7 пятниц на неделе. А во-вторых дисциплинирует заказчика, побудит его решать все вопросы ещё на стадии согласования.
Дополню, что в статье неявно (или явно под "клиентоориентированностью") подразумевается постулат "Клиент всегда прав". Но это - не так. Существуют случаи, когда, например, под видом дополнительных доработок (которые вроде и небольшие, но и в ТЗ их нет) идут попытки вынудить исполнителя нарушить сроки и тем самым вывести на штрафные санкции. И это только одна из мотиваций, которые могут быть у заказчика. Поэтому фразы, приведенные в статье, лучше пометить не как "запрещенные", а как "не рекомендованные". А решать все-таки ситуационно.
Вы знаете, я сам сделал много проектов и как РПО - еще столько же примерно.
Я ни разу не встречал мотивации клиента "затянуть сроки, чтобы выставить исполнителя на штрафняки". Новые требования - да. Пропустили что-то на фазе анализа - да.
Но штрафняки - нет.
по остальному, как прокаментил выше:
Смысл не в вылизывании попы заказчика. Смысл в запрете на конкретную фразу именно в таком звучании. Потому что - см статью.
Как эту фразу говорить правильно, можно прочитать например вот здесь:
https://habr.com/ru/articles/837070/ - "Как говорить заказчику НЕТ, когда все от вас хотят услышать ДА."
ТЗ обязательно - это мастхэв.
Заказчик не всегда прав - это факт
Но от того что вы тыкнете заказчика в то, что он кретин, ни проекту ни вам лучше не сделает. Это надо решать дипломатичнее. Иначе - будете ловить проблемы на проектах.
нет, вы не поняли смысла (возможно потому, что надо было передать его четче.
Смысл не в вылизывании попы заказчика. Смысл в запрете на конкретную фразу именно в таком звучании. Потому что - см статью.
Как эту фразу говорить правильно, можно прочитать например вот здесь:
https://habr.com/ru/articles/837070/ - "Как говорить заказчику НЕТ, когда все от вас хотят услышать ДА."
ТЗ обязательно - это мастхэв.
Заказчик не всегда прав - это факт
Но от того что вы тыкнете заказчика в то, что он кретин, ни проекту ни вам лучше не сделает. Это надо решать дипломатичнее. Иначе - будете ловить проблемы на проектах.
не знаю, где вы и с кем работаете, но даже не зовите меня..
Когда в ТЗ нужно внести правки есть 2 пути:
1) Разругаться с заказчиком за дополнительную оплату изменений и затянуть сроки реализации, при этом оплата по договору будет также задерживаться заказчиком.
2) Оценить изменения, если они укладываются в риски проекта, сообщить об этом заказчику и внести изменения. При этом оплата договора пройдет быстрее.
Кажется, что путь очевиден, но в реальности эмоции часто выходят на первый план и портят взаимоотношения между заказчиком и исполнителем.
В целом как программист я скажу что это работает в том числе и с программистами. Это не значит что начальство надо сожать на шею. Но если есть задача ее надо решать. Или не решать и уходить оставляя место тем кто будет решать. Отмазки типа нет в ТЗ заканчиваются тем что говорится что сейчас добавлю. Нет в должностной инструкции? Сейчас допишем.
тут знаете как у меня: кто-то должен беречь отношения с клиентом, а кто-то целостность системы и качество.
Я люблю, когда за первое отвечает Менеджер, за второе - Техлид. Первое часто противоречит второму (сделаем быстро из говна и палок), поэтому они периодически ругаются. И вот в этих спорах они должны рождать баланс.
Например: делаем какашечку, но прямо сразу планируем время на техдолг и РП зуб дает, что будет сделано нормально. Или сразу РП идет и увеличивает оценку заказчику. Да сложно , да больно. А надо.
Вот самая запрещенная фраза в IT....
БЭКАПОВ НЕТ.
Памятка менеджеру: Запрещённые фразы в IT. Часть 1