Отношение к ТЗ в современных ИТ-проектах
В мире накоплено немало знаний о том, как вести проекты. Разработаны ГОСТы, стандарты, методологии и целые идеологии, которые говорят нам, что нужно сделать, чтобы прийти от идеи к результату. Нам остается только выбрать рекомендуемый путь и следовать ему.
Сегодня я хочу поговорить об инструменте, который встречается на всяком пути, независимо от того, кто по нему идет, какая у него роль и какой управленческой методологией для ведения проектов он пользуется (или не пользуется).
Этот инструмент в широких кругах называется ТЗ — техническое задание. Еще он может называться спецификацией, user story, заданием или требованиями к разработке, суть одна — этот документ помогает нам прийти из точки A в точку B. Именно с такой позиции мы будем его рассматривать, независимо от формализации.
Но довольно банальностей! Перейдем к мясу.
Конфликтология ТЗ. Завязка
Роль ТЗ в проекте также важна как мореходу — карта, а врачу — план лечения. Но что-то мне подсказывает, что если первый заблудился, а второй ошибся с выбором лекарств, то им не придет в голову повесить все шишки на карту или план.
А как же получается, что среднестатистический подрядчик-разработчик ИС, выполняя работы для клиента, может спокойно прерваться, заявив «в ТЗ такого не было»?
В этом есть суть распространенного конфликта сторон. Он возникает при построении информационных систем, в широком смысле, а также в разработке приложений, сайтов, CRM, настольного ПО и прочих лендингов (ирония) в более чем половине случаев.
Как ни странно, но это ни в коем разе не зависит от масштабов и известности подрядчика и состава проектной группы. В данном конфликте подрядчиком может выступать именитая организация-интегратор, региональная веб-студия, команда энтузиастов-разработчиков или программист-фрилансер. Вообще не факт, что однажды кто-то из них вам не заявит отказ от продолжения работ и будет мотивировать это недоработкой ТЗ.
Оговорка:
Единственное, где в таком случае допустимы отсылки к ТЗ — это продукты, где требуется высокоточная разработка с заранее известными или рассчитанными характеристиками.
Сюда я включаю наукоемкое программное обеспечение для производств, оборонки, космонавтики и т.п. Здесь действительно трудно представить ситуацию, когда претензии заказчика, при точном исполнении по ТЗ, были бы обоснованы. Основными заказчиками такого ПО являются обычно (но не исключительно!) государство или связанные с ним компании.
Данный конфликт больше характерен при разработке коммерческих продуктов для бизнеса. Потребительские свойства такого продукта еще либо не изучены вовсе, либо не имеют осязаемых очертаний в представлении заказчика. Здесь мы как бы шагаем одной ногой в неизвестность, а другой опираемся на свой опыт, знания и схожесть характеристик с понятными нам работающими моделями или изделиями.
Что-то похожее испытывает штурман, когда ведет корабль к цели. Он еще не знает, куда придет. У него есть карта. А еще знания по навигации, небо над головой (а там звезды), радар, эхолот, интуиция и связь с берегом. А у врача, кроме плана, — 8 лет учебы и диагностическое оборудование, консилиумы, симпозиумы. Это их опорные точки и навигаторы в условиях неизвестности.
Впрочем, обо всем по порядку.
Убеждения, лежащие в основе конфликта
В основе любого поведения, действия или бездействия лежат убеждения. Иногда они находятся на поверхности, а иногда достаточно ловко скрываются от хозяина в лабиринтах его сознания. Копни чуть глубже — и вот оно — всплыло и никак не хочет тонуть. Не буду далеко ходить. Все они есть в этой статье. Беру их прямо из комментариев и перевожу на язык смыслов.
Я просто ресурс. Я не чувствую персональной ответственности за вклад в общее дело. Это менеджмент плохой.
А шутка ли? — Нет! Скорее убежденность, выраженная шуткой.
Скрытая агрессия как защитный механизм. К сожалению, этот паттерн поведения зачастую переносится и на заказчиков. Клиент по умолчанию причисляется к касте дураков. Такое часто можно наблюдать на дорогах: «А, красный ярис? — ну, точно курица поехала». Говорить о том, что такое восприятие контрпродуктивно для дела считаю излишним.
Компания виновата и ее размер. Да, по факту, может быть это и так. Но почему же врач стремится вылечить пациента независимо от масштабов клиники и наличия бюрократии в ней, а программист даже не пытается, что-то изменить? Клятва Гиппократа определяет?
Плохой KPI всему виной. Не буду даже пытаться уточнять ТЗ — не оплатят. Не хочу тратить время.
Снова заказчик не знает, чего хочет. У меня проблем нет. Дистанцируюсь от этого и отсижусь. Не хочу переделывать.
Ответственность не моя, а заказчика. Подписал ерунду — сам дурак.
Никто и никому ничего не должен, но заплатить в 100 раз больше надо :)
Снова никто и никому ничего не должен.
Сами мы не местные, за продукт отвечать не хотим, инициативы нет. Уход от ответственности. Объяснение потребностью бизнеса.
Теперь сгруппируем все эти убеждения и обнажим наголо:
Заказчик не знает, чего хочет / не в состоянии выразить свои желания
Задачи бизнеса решает компания/менеджмент (не я лично)
Это не оплачивается (не учтено в KPI), значит, и делать не буду
Не хочу переделывать без внятного техзадания
Ответственность за ТЗ на заказчике (на бизнесе), т.к. он его подписал
Никто и никому ничего не должен
Все эти убеждения задают климат работы над проектом и определяют ваши ограничения в нем. Причем не только единоличные, но и коллективные — чем больше таких убеждений приходится на участников проектной группы, тем вреднее это для ее коллективной динамики, пагубнее для результата и компании.
А теперь разберем каждое убеждение в отдельности и поймем, что с ним можно сделать с точки зрения психологии, собственного поведения и управленческого инструментария.
Заказчик не знает, чего хочет / не в состоянии выразить свои желания
Что сделать с точки зрения психологии? Допустить, что заказчик несовершенен. Что ему может быть трудно, в силу разных причин, сформировать образ конечного результата. Допустить, что он вовсе не обязан разбираться в технических тонкостях проекта. Принять тот факт, что его язык описания задачи может отличаться от вашего.
А еще представьте, что вы у врача. Вам было бы приятно быть выслушанными? Или будет достаточно безразлично-сурового «ну, что там у вас» и взгляд, такой, исподлобья? Возможно, вам трудно найти у себя в теле источник боли, вы мучаетесь, боль неоднородна и непонятна. Вы бы хотели, чтобы доктор помог вам определиться с локализацией и причиной? Или, удостоившись дежурной пальпации и снисходительного простукивания, удовольствуетесь этим и ношпой, выписанной вслед? И добивание: «приходите через две недели, если сильнее заболит».
Что сделать физически? Помочь клиенту осознать свою проблему. Задать компетентные вопросы, проясняющие детали желаемого результата. Собрать необходимую информацию. Предложить разные варианты решений. Обозначить границы таких решений. Выработать удобные для сторон правила взаимодействия, отвечающие на вопрос «как мы будем общаться?». Определить подходящую методологию для ведения проекта.
Что сделать управленчески? Поставить взаимоотношения с клиентом выше ТЗ на уровне принципов компании. Определить правила взаимодействия с клиентами для всех вовлеченных ролей. Пресекать на уровне разговоров и переписок отношение «клиент — дурак». Продвигать среди персонала мысль, что именно клиент приносит компании прибыль. Не будет у компании прибыли — не будет зарплаты и премий у сотрудников. Ориентировать проектные команды на выстраивание долгосрочных отношений с клиентом. Задать KPI так, чтобы вознаграждение лиц, участвующих в постановке и сдаче работ клиенту, росло по мере поступления новых заказов от него.
Дополнительные пояснения. Ну, допустим, заказчик не знает, чего хочет. И что?
Помогите ему узнать это! Сделайте это частью вашей работы, если вы почему-то до сих пор считаете, что это не в ваших силах. Заказчик приходит к подрядчику с проблемой, с болью. И для начала хочет быть выслушанным. Развесьте уши — слушайте внимательно, не перебивайте, делайте вид, что вам интересно. А вам неинтересно? Тогда какого черта вы делаете на этой должности? Кто допустил вас до общения с заказчиком?
Может не стоит уже относиться к заказчикам как к дуракам? Предоставьте им сервис, внимание. Кем бы вы ни были. Какая в самом деле разница, какая у вас роль? Называетесь ли вы программист или аналитик, консультант или тим-лид. Проявите простые человеческие качества, которые покажут заказчику, что вы заинтересованы сделать его бизнесу хорошо, а не вызвать у него ощущение безысходности от потраченных денег и неработающего работающего строго по ТЗ проекта.
«Доцент тупой, но аппаратура при нем, при-нем!» А еще ваши деньги — они тоже при нем. Он их платит бизнесу: вам лично или той компании, которую вы представляете. Если вам выпало обслуживать этого непонимающего человека, составлять для него бестолкового ТЗ, то сделайте это, хотя бы один раз, по первому разряду!
Просто попробуйте. И вы увидите, что дураки вовсе не являются таковыми при вашем активном участии. Волшебным образом они превращаются сначала в непонимающего клиента, потом в активно сотрудничающего, затем они раскрываются, располагаются к вам доверием как к профессионалу высокого класса, несут вам свои деньги и дорожат полученным опытом!
Кроме того, активно сотрудничающий клиент набирается сноровки. И даже, если однажды он был «туповат» по вашим меркам, то научив его работать, вы приобретаете в его лице не только постоянного заказчика, но и бесконечно признательного друга!
Задачи бизнеса решает компания/менеджмент (не я лично)
Что сделать с точки зрения психологии? Должно быть вы также уверены, что вас лечит больница, а не врач, обслуживает магазин, а не продавец, ну, вы поняли дальнейшую логику, да?
Если вы работаете в коллективе, но не чувствуете личной ответственности за исход дела, то стоит найти в себе мужество сделать это. Признайтесь, что в случае, если проект будет закрыт хорошо, то вы будете чувствовать свою причастность к этому, даже если не общаетесь с клиентом лично, а, например, просто запрограммировали по классному ТЗ. Но если в ТЗ обнаружится косяк, то в этом случае вы скажете, что просто сделали, как было указано. Чувствуете фальшь?
Это как в футболе болеть за своих: выиграли — мы, а проиграли — они. Инфантильно, слабовольно, жидко.
Что сделать физически? Если вы программист и кодите по ТЗ, спущенному сверху, увидели в нем ошибку, несоответствие или другую явную дичь, то вам стоит подойти к ответственному и сообщить об этом.
Если ТЗ делали лично вы — все то же самое. Только идете к клиенту, уточняете задачу и вносите корректировки в проект. Страшно? Больно? А кто сказал, что это легко? Выявить ошибку на ранних этапах работы обычно гораздо дешевле, чем сделать это в дальнейшем. Гораздо страшнее заложить из-за этого неправильную архитектуру в проект и узнать об этом на этапе приемо-сдаточных испытаний.
По моим наблюдениям все упирается в банальные страхи типа «клиент не заплатит», «уволят за ошибку» или «я буду выглядеть дураком». Признаюсь, что за свой 17-летний опыт проектной работы ни разу не видел таких последствий. Обычно, смелость в принятии сложных решений ценится окружающими и, если вы сумели вырулить ситуацию, то это только добавит вам профессиональных очков. А вот, если скрыли свою ошибку и об этом стало известно менеджменту и/или заказчику — вот тут уж палок не оберешься! О том, как нивелировать последствия таких ошибок, пожалуй, стоит написать отдельную статью.
Что сделать управленчески? Выявлять инициативных и ответственных сотрудников с тем, чтобы дать им больше личной ответственности в рамках проекта. Поощрять инициативы. Ввести коллективную ответственность через KPI.
В качестве примера: если задача из тестирования возвращалась на доработку более N раз, то использовать понижающий коэффициент от бонусной части за проект для программиста. Одновременно с этим заложить в процессы компании прозрачные механизмы эскалации проблем в случае обнаружения дефектов в ТЗ. Хорошей практикой будет «задай 7 вопросов». В рамках этой практики ТЗ не просто спускается программисту, но и обязывает его задать не менее 7 вопросов по данному ТЗ постановщику. Больше можно, меньше нельзя. Отслеживать работу этого механизма.
Ввести практику, при которой одновременно с ТЗ пишутся кейсы для тестировщиков. После чего ТЗ вместе с кейсами передается программистам. Проводить с персоналом коммуникативные тренинги, поощрять обмен информацией и сплоченность проектной команды.
Дополнительные пояснения. Подход «моя хата с краю» действительно встречается. В тех компаниях, где много бюрократии и формальностей между отделами эта проблема стоит особенно остро. Общая рекомендация такая: объединять отделы, формировать проектные команды, выстраивать управление ИТ-проектами не по вертикали, а по смешанному типу. Это когда специалисты из разных отделов физически работают вместе. Их объединяет одно пространство — они могут общаться друг с другом в любой момент, когда того требует ситуация.
Нещадно сносить всю бюрократию: согласования, подписания, служебные записки и т.д. Проблемы решаются здесь и сейчас — ключевые лица всегда доступны. Процессы решения проблем прописаны и известны участникам проекта.
Это не оплачивается (не учтено в KPI), значит, и делать не буду
Что сделать с точки зрения психологии? Осознать, откуда в компании появляются деньги. Понять, за что действительно платит клиент (спойлер: нет, не за работу по ТЗ). Постигнуть ценность таких понятий как взаимопомощь, взаимовыручка, профессиональный долг. Определить свою нравственно-этическую позицию в компании. Подумать над тем, когда компания получает больше пользы от вас: когда вы создаете ей проблемы или когда решаете проблемы? Подумать, в каком из этих случаев будет расти ваше вознаграждение и как можно повлиять на него.
Что сделать физически? Продолжать так же качественно делать свою работу (как и сейчас), но уже с осознанием того, что я описал с точки зрения психологии. Если вы напрямую работаете с заказчиком, например, вы — фрилансер, то доходчиво объяснить клиенту, за что он вам платит и как следует описать процесс изменения требований в единой связи с их оплатой, убедиться, что вас поняли.
Кстати, если вы до сих пор не знаете, за что вам платит клиент, спросите прямо у него — узнаете много интересного. Когда узнаете, сделайте это своей сильной стороной. Если вы наемный специалист, делайте все то же самое: качественно работайте, подойдите к руководству и узнайте, за что оно платит вам. Предложите ваше видение о том, как можно решать задачи клиентов эффективнее, как не допускать ошибок при постановке задач и что вы можете сделать со своей стороны, если увидите их на своем участке работы.
Предложите включить эти изменения в процессы компании с их учетом в KPI. Если ваше предложение ценно — вас услышат. Если нет, это будет поводом задуматься, а в той ли компании вы работаете. Но если вы ничего не сделали, значит, вы всем довольны и нечего тогда говорить о том, что это не оплачивается — вы просто лентяй!
Что сделать управленчески? Таки внедрить процессы критической обработки ТЗ программистами с возвратом на уровень постановщиков, в случае обнаружения косяков. Обеспечить прозрачность и выполнимость таких процессов. Изменить KPI по рекомендациям «Задачи бизнеса решает компания/менеджмент (не я лично)». Отправить всех методистов, постановщиков и аналитиков на тренинги по написаниям ТЗ. Выявить и уволить людей, допускающих выполнение заведомо некорректных требований в ТЗ без их предварительной верификации.
Дополнительные пояснения. Часто за формулировками «это не оплачивается» стоит банальная лень и страх изменений. Обычно у таких специалистов, все в действительности хорошо — оклад их устраивает, а больше денег им и не нужно. Перестраиваться они не хотят, а потому избегают любых попыток привлечь себя к анализу требований.
Такие сотрудники 100% формалисты и бюрократы. На вопрос «чей косяк?» они всегда сошлются на «убогое ТЗ», «криворуких постановщиков» и трудовой договор. Они редко признают свои ошибки, т.к. считают, что их допустил кто угодно, но не они. Если перед ними встает выбор сообщить об ошибке или допустить ее — сделают так как написано в ТЗ, т.е. с ошибкой, даже если спокойно могли бы избежать этого. Являются очевидными саботажниками.
Могут работать изолированно, например, на проектах по поддержке. В остальных случаях лучше уволить.
Не хочу переделывать без внятного техзадания
Что сделать с точки зрения психологии? Тут обычно подразумевается, что кто-то (обычно заказчик или аналитик) должен предоставить это техзадание автору убеждения. Подать, так сказать, на блюдечке с голубой каемочкой.
Чтобы понять всю абсурдность такой позиции достаточно представить как врач, после неудачных попыток вылечить вас, просит сделать для него (более) внятное ТЗ. А если, в автосервисе от вас вдруг попросят такое ТЗ, как вам? Понравится?
Ваши опасения вполне понятны. Но они бы не вылились в переделки, если бы изначально вы провели более качественную диагностику проблемы и верификацию требований. Таким образом, если перед нами замаячило такое убеждение, то в 95% случаев мы допускаем ошибку раньше — скорее всего, спешим быстрее начать работу, не проявляем достаточной вовлеченности при выявлении проблемы, описании конечного результата. Допускаем промахи во взаимодействии с заказчиком (постановщиком), не погружаемся в детали.
Если вы отвечаете за непосредственный сбор требований и создание ТЗ, то следует осознать, что именно в вашей зоне ответственности находится постановка задачи: понятная и вам, и заказчику, и непосредственному исполнителю.
Что сделать физически? Если вы — исполнитель ТЗ, то нужно активнее участвовать в сборе требований и их верификации и формализации. Об этом я уже писал выше.
Если вы — постановщик задачи, пройдите дополнительные тренинги по взаимодействию с заказчиками и подготовке документации. Отличным вариантом будет разделение большого проекта на несколько маленьких. Так ТЗ на каждый проект будет меньше, а результат каждого этапа более предсказуем и понятен для заказчика и исполнителя и менее трудоемок в осознании будущего результата и реализации. При этом цена ошибки будет меньше.
Возможно, что стоит сделать предложение руководству о переходе к гибким методологиям ведения проектов — там меньше бюрократии на идеологическом, т.е. определяющем все остальные процессы, уровне. Сместить фокус внимания на заказчиков и допустить, что задача может видоизменяться на ходу.
Что сделать управленчески? Организовать совместную работу над ТЗ аналитиками и тестировщиками. Предполагается, что одновременно с написанием ТЗ ведется подготовка сценариев тестирования и все это передается заказчику на ознакомление. Смысл в том, что хороший сценарий тестирования обычно достаточно нагляден. Если его передать заказчику перед началом работ, то ему будет проще оценить, соответствуют ли его желания описаниям. А у разработчиков будет меньше вариантов ошибиться. В рамках управленческих подходов следует также зафиксировать процедуры совместной работы в административных регламентах компании. Рассмотреть переход на agile.
Дополнительные пояснения. Заказчик имеет полное право не понимать, не уметь или не хотеть делать для вас ТЗ. Ему важен конечный результат, который закроет проблемы его бизнеса. Если принять это утверждение как данность, то перед вами откроются следующие возможности:
Быть на голову выше своих конкурентов, работающих по схеме «Дайте ТЗ». Вместо этого стоит перейти на схему:
проблема (ставит заказчик) — анализ (делаете вы) — предложения (вы) — решение (вы)
+ постоянное взаимодействие с получением обратной связи и корректировка действий.
Получать больше денег и уменьшить количество бюрократии. Заказчики охотно платят за отсутствие геморроя, волокиты и бумажек. Покажите им, что умеете взаимодействовать, быть на связи, нести ответственность и они будут платить вам рублями и преданностью.
Ответственность за ТЗ на заказчике (на бизнесе), т.к. он его подписал
Что сделать с точки зрения психологии? Уверен, что бизнесы, которые не поймут, что бюрократия — это зло, скоро умрут. Говоря о бизнесе, я конечно же, имею ввиду менеджмент и сотрудников, стоящих за ним. Оглянитесь вокруг: сегодня вы можете вернуть товар в магазин без чека, просто, если вам не понравится его вкус или качество! Вы можете заказать на дом одежду, померить и вернуть обратно, ничего не купив. Принести в ремонт ботинки или сумку, находящиеся на пожизненной гарантии, абсолютно бесплатно и без чека.
Во всех описанных случаях бизнес несет некоторый расход, который во многом больше покрывается такими выгодами как лояльность клиента. Осознанно выбирая путь отказа от бюрократии и доверия клиенту, мы окупаем это в других не менее важных аспектах.
Варенье не понравилось — дали другое — классно! Буду покупать в этом магазине! Не смог попасть к врачу в этот раз, но приду в следующий, т.к. со мной были вежливы и обходительны именно здесь. Не подошел спортивный костюм — обменяю через пару недель (но тоже в этом магазине, ибо классно).
О чем это я и как это связано с ИТ? А это об уровне зрелости компании, о понимании тонких материй. Это не про то, как зачеркнуть ценник и продать куртку «со скидкой», а когда у нее сломается молния развести руками. Не про то, как поставив на весы лишний грузик, обвесить на картошке и заработать рубль здесь и сейчас «на дурака». Это про игру в долгую.
В этой парадигме вы ставите во главу угла качество, доверие, ответственность, порядочность и СО-трудничество. Здесь приставка «СО» выделена крупным т.к. означает, что вы садитесь с клиентом в одну лодку и движетесь в одном направлении. Вы СО-причастны к его проблемам.
Вы экскурсовод клиента в области ИТ. Вы сажаете его в автобус и с его СО-гласия проводите ему путешествие по миру технологий по заранее подготовленному маршруту (ТЗ). При этом вы готовы гибко менять этот маршрут по его запросам или в случае, если какая-то дорога вдруг окажется закрытой, изменить первоначальный план, но сохранить его впечатление от поездки. Путь даже с некоторым локальным убытком.
В этом качественно иной подход к современному ИТ-бизнесу. Осознав это, вы сможете зарабатывать несравненно больше. Разбюрократизируйтесь в своей голове! Сейчас это делают даже государственные поликлиники и почта России :)
Что сделать физически? Спросить у клиента, что его действительно не устраивает и доделать работу. В моем опыте часто бывает такое, что клиенту не хватает какой-то мелочи, но при этом программист или компания встает в позу и «принципиально» не дорабатывает на 99% выполненную программу.
К чему такая принципиальность? Просто сделайте этот 1% работы и выставьте дополнительные деньги к следующему счету. Ну, нет же, надо портить впечатление о себе этими бесконечными боданиями, доказывая свою правоту и лишая клиента возможности порекомендовать вас или вашу компанию своим знакомым.
Возьмите себе дополнительные очки за счет вашей гибкости и умения следовать к результату, а не потакать формальностям!
Что сделать управленчески? Перевести внутренние процессы согласований в электронную форму. Сместить фокус с бумажек на СО-трудничество, поставить во главу угла взаимодействие вместо формальностей. Научить аналитиков и прочих постановщиков визуализировать будущие результаты работы (прототипы, мокапы) — они, обычно, более внимательно изучаются заказчиками. Хороший прототип, особенно динамический, может покрыть в себе до 90% ТЗ. Остальное покрывается описанием процессов в каких-нибудь понятных нотациях (типа BPMN) и верхнеуровневыми (небольшими) ТЗ.
Дополнительные пояснения. А не будет дополнительных пояснений здесь) Мысль достаточно полная, чтобы начать меняться прямо сейчас.
Никто и никому ничего не должен
Что сделать с точки зрения психологии? Попытаться осознать это стихотворение. Хотя не надо пытаться. Вы ведь вовсе не должны.
Ну, когда же наконец я пойму: я не должен ничего никому, я не должен ничего никому, в том числе и себе самому.
Спи спокойно, мой Господи-Боже, обнимая вселенскую тьму, никому ничего ты не должен, в том числе и себе самому.
И когда ты молитву услышишь, медитацию, то или се, ты и волосом не поколышешь, потому что не должен, и все.
В.Л. Леви
Что сделать физически? Уволиться. С такими убеждениями начальник не должен платить вам зарплату, а вы не должны работать на него. Я уж совсем не говорю о ТЗ — это за гранью понимания.
Что сделать управленчески? Проводить более тщательный отбор кандидатов на работу.
В качестве заключения
В качестве заключения хочу привести в пример один любопытный опрос, который наглядно отражает отношение аудитории к ТЗ. Опрос приведен в этой статье https://habr.com/ru/post/340052/
И хотя на момент публикации результатов трудно считать выборку из 296 пользователей репрезентативной, но кое-какие выводы о наблюдаемом тренде, все же, сделать можно.
В лидерах по распределившимся голосам следующие тезисы:
Перед сдачей работы не проверяю, все ли сделано по ТЗ — 103 голоса
Читаю ТЗ по диагонали — 100 голосов
Что это означает для нас с вами и рынка в целом? Считаю, что ничего хорошего. И то, и другое говорит о том, что заказчик не получит ожидаемый результат. Двойные потери: первый — на этапе чтения ТЗ по диагонали, второй — на момент сдачи работы, абсолютно точно приведут нас к доделкам/переделкам. При таком подходе говорить о хорошем климате на рынке ИТ-услуг, увы, не приходится.
Но не будем же пессимистами, коллеги! Все начинается с головы. Давайте меняться и приносить пользу друг другу во взаимодействии и соучастии. Это в наших силах.
Классных проектов вам :)
