Умоляю, уберите скорее от экранов перфекционистов и беременных своей чудесной идеей заказчиков. Пост содержит боль. И вообще, проконсультируйтесь с вашим психотерапевтом.
Я — аналитик и уже привык: все и всегда происходит не по ТЗ. Это норма, и удивления давно у меня не вызывает — я уж стал думать, что так оно и надо. И тут внезапно увлекся машинным обучением, пошел на курсы, а там надо сделать задание по программированию, а потом проверить три чужих таких же. Я посмотрел на то, как разработчики выполняют учебные задания, и в голове сразу же сложился пазл, как же это все так получается-то.
Сразу же хочу ответить на несколько важных вопросов.
А может, это не настоящие программисты, а просто начинающие безрукие упыри?
Нет! На этих курсах есть этап знакомства, и там все обычно пишут, что давно в разработке и решили квалификацию повысить. Да и сами курсы — довольно-таки зубодробительные, с большим количеством матана и линейки. Не для джуниоров совсем.
А как же можно проверять чужие задания, если ты сам не шаришь?
Задание устроено гениально! Вам дают код, и в нем есть места, куда нужно самому дописать свой код, а есть места, где нужно ответить на вопросы текстом, сделать выводы и обобщение. Когда проверяешь сокурсников, то иногда понимаешь, как ту же функцию можно было реализовать иначе. Кайф!
В чек-листе примерно 40 вопросов, в духе: “В задании просили вывести 12 признаков, а не 13. Проверьте, действительно ли признаков 12.”.
Все дело в том, что убрать 13-ый признак оказалось не так легко. Пришлось изрядно вкурить доков, чтобы научиться просто так, опа, и убирать 13-ый признак в ассоциативном массиве, не городя дурацких циклов.
Ну хорошо, ты проверял задания разрабов, с каким-то опытом, и что же тебя там так поразило?
А поразило меня, ребята, повальное наличие 13-ого признака. Просто никто не стал заморачиваться!
40 тестовых вопросов я бы разделил на группы:
* Нужно использовать какой-то метод, о котором написано. Обычно, все справляются.
* Нужно реализовать какую-то задачу. Обычно, тоже справляются.
* В этой задаче нужно учесть важные детали. Есть детали простые, например, подписи к графикам. На это все забивают. Хотя в каждом чек-листе на проверке есть пункт “А есть ли у графиков подписи?”. Сижу, проверяю задания — ни у кого нет подписей!
Дальше есть мелочи, о которых не сказано, как они делаются. Ну, например: “Вывести коэффициент альфа”. Чтобы его вывести, нужно немного вкурить доки или догадаться. Почти все забили.
И еще есть мелочи, с которыми нужно задолбаться: “Вывести минимальный коэффициент альфа для каждого столбца”. А такого метода нет, нужно делать вручную — никто не стал заморачиваться.
Ну это же мелочи! Главное, ведь, понять принцип во время обучения! Что ты привязался?
Во-первых, посмотреть, например, альфы просто необходимо для понимания принципов. Во-вторых, есть еще вопросы типа “вывод”, и если неряшливо относиться к мелочам, то в выводах начинается жара. Например, у человека на графике “шпилька” в потолок, а он в выводах пишет, как все красиво сходится к теоретическому нормальному распределению.
Ну ладно гнать! У тебя у самого, что ли не было багов?
Были. У меня тоже ничего не сходилось. Это было видно, и я переделывал. Я замучался с 13-ым признаком, замучался с альфами.
Надо просто пилить код, пока корректный ответ на вопрос задания не будет найден. И, в отличие от реальной жизни с недоделанными вопросами, дальше не пропускают.
И тут меня впечатлил второй важный момент. Для того чтобы вкурить, как все работает, приходилось много гуглить. И, естественно, попадались чужие проекты. Многие даже в Гитхабе. А какие-то — висящие на домене какой-нибудь конторы, которая предлагает свои услуги по разработке. Хотя вываливать задания, конечно, запрещено. Но кто читает правила? Ну так вот, мое грустное открытие в том, что очень многие авторы этих проектов бросили обучение год, два или более назад.
Да что там говорить! Был даже парнишка, который заморочился и выбросил-таки 13-ый признак из списка, и даже одну альфу вывел. Вот, правда, под конец этот супермен подустал, поэтому забил на графики вообще, а в выводах написал: “Ну тут все аналогично.”
Благодаря этому опыту, у меня родилось понимание, как же все происходит не по ТЗ
Сделали несколько пунктов, дальше заморачиваться не стали, а потом устали, время поджало, и вообще кусок решили не делать.
Ну, не то чтобы я этого раньше не понимал, и не то чтобы я сам в этом плане безгрешен, но тут прямо все, как на ладони. Сижу, делаю задания с альфами и сразу понимаю, что не увижу их на проверке.
Да знаю я этих рукожопов, я не такой!
Конечно, иногда попадаются разрабы высокой четкости. С ними есть сложность: они как посмотрят на ТЗ, в котором есть мутные места, так сразу говорят: “Тут какой-то бред, я с таким не работаю!” Год не работают, два не работают, начинают голодать и таки ввязываются в какой-то ад. Ну или думают: “Ну его нафиг! А стану-ка я лучше инструктором по парашютному спорту или скалолазанию”.
А бывает еще такой вариант. В ТЗ все — очень четко, разраб забил и давай юлить: “Ой, у тебя запутано! Ой, а я думал не так, а по-другому.” И клиенты тоже любят: “Ой, а мы думали, что это само собой разумеется.”
Вместо заключения: “И как с этим жить?”
Да так же, как и раньше жили:
— обязательный чеклист по каждой задаче;
— мало пунктов на каждый этап;
— обязательное обсуждение каждого пункта голосом;
— короткие спринты.
Конечно, заказчик хочет полный фарш, и чтобы ему показали обязательно готовую систему. Надо этому сопротивляться и с болью формировать чеклист из малопунктов на короткий этап. И да, я люблю голосом проговорить каждый пункт и с заказчиком, и с разрабом. А еще люблю прописать прямо в ТЗ, что реализовано не будет.
А бывает, забью на что-то из этих светлых принципов зачем-то и страдаю…
PS: zharikovpro дополняет, про чеклисты на основе макета:
Комментарии (95)
DSolodukhin
16.10.2017 13:26С ними есть сложность: они как посмотрят на ТЗ, в котором есть мутные места, так сразу говорят: “Тут какой-то бред, я с таким не работаю!”
Хм, аналитик написал мутное ТЗ, но виноват разработчик? Интересно.
Я, как разработчик, не работаю с мутным ТЗ, потому что не понятно, что именно я должен сделать. Я понял написанное вот как-то так, аналитик имел в виду другое, а заказчик вообще хотел третье. Написано ТЗ непонятно, неоднозначно или неполно, я иду и пинаю аналитика, чтобы у меня было полное, ясное и однозначное ТЗ, это его работа в конце концов.
Может быть я работаю в какой-то особой конторе, но у нас если реализация отличается от описанного в ТЗ, то её просто не пропустит QA и отправит обратно на доработку.
krivotester Автор
16.10.2017 13:30Понимаю вас. При этом чем хорош случай с курсами, что там все однозначно. Нужно написать код, и получить совершенно однозначные результаты, которые либо проверят однокурсники, либо проверят парсеры.
Значит дело не всегда в мутных ТЗ?
Кстати про мутные ТЗ, я в позапрошлой статье тоже писал «ТЗ высокой четкости»
sbnur
16.10.2017 13:42Неясная ситуация
Есть ТЗ, есть несоответствие результата с ТЗ
Если оплата прошла — значит ТЗ было мутное или нужно не то, что в ТЗ, или оно вообще не нужно ТЗ(оно для проформы)
Какие еще варианты?krivotester Автор
16.10.2017 13:48Бывает, когда в чек-листе 40 маленьких однозначных пунктов, и чего-то не хватает -)
Не сталкивались?
mayorovp
16.10.2017 13:45Я разработчик, и я с ТЗ не работаю. Вместо этого я работаю по постановкам, написанным аналитиками. И там зачастую написана какая-то хрень. Есть у нас пять аналитиков, которые умеют писать постановки, остальные пишут дикую хрень.
Когда мне прилетает слишком дикая постановка — я отказываюсь по ней работать пока ее не приведут в порядок (при поддержке начальника отдела и ведущих программистов), одного аналитика я так довел до слез. Но чаще бывает что постановка в целом понятная, но пара абзацев в ней — хрень. Или мне нужно исправить баг в программе, которую писал кто-то другой… по постановкам в которых была написана хрень.
И когда в такой постановке оказывается слишком много хрени, я ее начинаю пропускать и могу уже не заметить действительно важную информацию.
Разновидности хрени:
1. Код прямо в постановке
К примеру, однажды мне довелось чинить ETL-процедуры. На каждую из них была написана постановка, в которой был приведен код SQL-запроса который нужно было выполнить. И этот запрос на сотню строк работал неправильно: либо пропускал строки, либо дублировал их, либо просто выполнялся слишком долго. Ну и как его чинить-то когда он записан в требованиях?
И даже если опустить формальности — как понять что этот код должен был делать?
2. Ритуальные заклинания
Когда делается много типовых модулей — то программисты выносят повторяющиеся вещи в компоненты или подпрограммы. А в постановках аналитики обычно используют копи-паст. Подобные блоки скопированного текста превращаются в ритуальные заклинания, сопровождающие каждую новую постановку. И когда в очередной постановке эти заклинания оказываются чуть-чуть в другом порядке — никто этих изменений не замечает пока не прилетает блокер с прода.
3. Копи-паст внутри постановки
Допустим, есть объекты пяти разных типов, которые нужно обрабатывать одинаково, и еще один тип объектов с особой обработкой. Что делает аналитик? Он копирует описание первого типа объектов 4 раза, исправляя название.
А потом программисту надо в уме делать дедупликацию. Иногда получается неудачно.
krivotester Автор
16.10.2017 14:08Согласен, это все очень печально и приводит к ложной реализации. Стараюсь избегать такого в работе и даже писал уже в позапрошлой статье про «ТЗ высокой четкости» про примеры адовее ваших -)
При этом курсы хороши тем, что в курсах с ТЗ все в порядке. Они реализуемы и пропущены через многих разрабов, которые там повышали уже квалификацию.
Mexis
16.10.2017 13:45+1ТЗ высокой чёткости требует высокого опыта разработки. Нельзя написать чёткое ТЗ на средний проект простому смертному и не забыть ничего. Я в разработке уже 15 лет и сколько бы не стралася довести ТЗ до идеала, всё равно есть просчёты с которые попросту не учёл. И это не связанно с тем, что мало опыта, просто на большенство клиентов не хочет платить за потраченное время на написание ТЗ, по этому пишется сокрашённая версия с десяток страниц и всё. А далее уже всё в процессе, ну всё самое важное и значимое естественно расписанно…
krivotester Автор
16.10.2017 13:51Скажу вам больше. На супер четкое ТЗ большого может жизни не хватить -) А может не хватить жизни на его прочтение.
С другой стороны, маленькие проекты, или маленькие этапы отлично документируются.
Однако, большие системы все равно приходится описывать, оценивать, проектировать. По возможности работоспособными -)Mexis
17.10.2017 11:49+1Согласен полностью, что на большой проект не хватит жизни. Я говорю про маленькие и средние а у средних уже начинается конкретные запарки. Мы не в силах продумать все нюансы и многое вылазит только в процессе.
В 90% случаях я не получаю ТЗ от клиентов… мне говорят, что приблизительно им нужно.
Я пишу ТЗ на понятном языке для клиента, после спрашиваю, всё ли это? Если он говорит, да, вроде бы всё, я его предупреждаю о том, что если мы что-то забыли в ТЗ, то возможно это будет доработка сверху, всё зависит от сложности.
Пишу ТЗ для программистов, прохожу проект с главным программистом. Накидываем структуру базы и определяемся по цене.
После я подписываю договор с клиентом.krivotester Автор
17.10.2017 12:01Согласен, у меня тоже с годами приключений все пришло к похожей схеме -)
evgenicx
16.10.2017 13:45Как автор отметил — есть разработчики которые придираются к ТЗ, ибо в нем много темных мест и есть разработчики которые делают так как написано и как понятно им и не уделяют внимание каким то хитрым особенностям требований. Про первых все понятно — но как правило им говорят смирись и работай. Про вторых, вообще это стиль работы, делай что понятно, непонятное потом разберем. Как правило никто не хочет ждать пока разберутся с требованиями, простой работы программиста никому не нужен, плюс все равно хотят увидеть что получилось в первом приближении и доработать требования — поэтому всегда торопят, а потом создается приличный скоуп багов, и журят программистов что они все еще косячут. Да и к тому же любое требование может представить всегда в ином свете.
Поэтому, все гораздо проще — проблема именно в ТЗ, ибо оно не передает эту информацию для программиста в правильном ключе.krivotester Автор
16.10.2017 13:55Когда мне не задают вопросы по ТЗ, я уже начинаю напрягаться. Обычно причина одна: «не читал». Так что, если придирается, значит читал, круто!
С другой стороны конечно нужно смериться и ехать. Максимальная детализация в обозримые горизонты времени даже по маленьким задачам не достижима обычно.
И все же, история с курсами отлично показывает, что проблема не всегда в ТЗ. Там-то ТЗ всегда однозначные! Их уже выполняли многие разрабы за несколько лет. Получали результаты, которые можно было на парсере проверить к примеру -)
JekaMas
16.10.2017 13:50Сколько заданий вы проверили? Скольким различным учащимся они соответствуют? Сколько из них допускали приведенные ошибки?
krivotester Автор
16.10.2017 14:00По началу проверял по 10-12 на каждую тему, никак не могу поверить. Теперь устал, проверяю по 3 (это минимум для зачета) на каждую тему, все одно и то же. Причем люди разные всегда, т.к. я медленно учусь и отстаю, люди меняются за время пока я тему прохожу.
Последний раз проверил 3 задания и во всех были приведенные ошибки. В предыдущем курсе 80% где-то не ставили подписи к графикам. Специально исследования не проводил.
Конечно можно прямо взять и посчитать репрезентативную выборку, оценить ЦА, посчитать отклонения. Если бы хотел бы дисер про это писать — занялся бы. А так не достаточно энтузиазма -)JekaMas
16.10.2017 14:19Тогда да, похоже на системное заболевание. А народ в основном с высшим или нет?
krivotester Автор
16.10.2017 14:23Там без высшего смысла нет, в первых же лекциях матричное исчисление, системы линейных уравнений, регрессия, центральная предельная теорема. Думаю, что ребята без высшего технического, ну хотя бы без первых 2-3 курсов срезались на первых же лекциях.
JekaMas
16.10.2017 14:29Ну я без высшего, но курс ODS в первой двадцатке закончил, затем окунулся в kaggle. Математика осваивается или самостоятельно или, к примеру, с онлайн курсами.
Мне поэтому не очень понятен ваш комментарий. Выпускник тех вуза может знать или не знать математику, чаще, наверное, знает, но correlation doesn't imply causation.krivotester Автор
16.10.2017 14:33Есть самородки, не спорю. При этом одно дело вспоминать, и другое дело по сухому с нуля. Не каждому дано.
Если у вас дар, не стоит это экстраполировать на всех -)))
samizdam
17.10.2017 19:35Вот интересно, самородками можно назвать персонажей без высшего, способных пройти курс.
А какой эпитет подобрать для персонажей с высшим, которые не могут осилить? Полагаю таких ой как немало, относительно общего количества получивших в.о.krivotester Автор
17.10.2017 20:53Я на последних курсах преподаю бывает тех. вуза, так вот не все знают что такое функциональная зависимость.
zharikovpro
16.10.2017 14:12+1> И как с этим жить?
Расширю имеющийся список. Чтобы не забыть про мелочи, я пишу чеклисты приемки на основе макета. Макет — очевидное представление результата, по нему можно визуально быстро понять если результат совсем негодный. Если в целом выглядит нормально, можно дальше по чеклисту проверять. Можно и на самом макете подписать пункты чеклиста, если они короткие. Пример из статьи про графики тут замечательно подходит.
zharikovpro
16.10.2017 14:21> Благодаря этому опыту, у меня родилось понимание, как же все происходит не по ТЗ
Все дело в мотивации, имхо. Она напрямую вытекает из схемы организации труда. За что разрабу платят, то он и делает.
Например, сидит в конторе штатный разраб и каждый месяц получает зарплату. Т.е. ему платят за присутствие в офисе. Денежной мотивации делать все сразу все по ТЗ и без багов у него нет, он и не делает.
В это же время на фрилансе разрабу платят за результат по ТЗ и без багов, а все дефекты (несоответствие ТЗ и баги) разраб устраняет за свой счет. И НЕ получает денег и новых заказов от заказчика, пока не устранит дефекты. Тогда разраб замотивирован делать все сразу правильно и в полном объеме.
Тут я сознательно утрирую, конечно есть промежуточные варианты. Многие фрилансеры также безответственно подходят в работе как и штатные сотрудники. И тогда у них закономерно будут хронические проблемы с поиском и удержанием доходных клиентов.krivotester Автор
16.10.2017 14:27А мне кажется дело в культуре. Вот есть люди, которые и за деньги и без денег вовсе будут делать правильно. Просто потому, что они верят, что надо делать правильно.
А есть люди, которым сколько не плати, сколько не штрафуй — ничего не меняется, одно расстройство.zharikovpro
16.10.2017 14:38> А мне кажется дело в культуре. Вот есть люди, которые и за деньги и без денег вовсе будут делать правильно.
Есть, но таких очень мало. Если не организовать работу на результат, «бескультурные» будут его портить и снижать эффективность.
Если отбирать только «культурных», то все равно есть риск ошибиться при найме, да и человек потом может разлениться.
Если же отбирать «культурных» людей и работать по правилам, которые дают результат — получается комбо. Но в таком случае даже не нужно как-то специально отбирать «культурных». Достаточно просто выбирать людей, которые будут работать по правилам эффективной организации труда. «Некультурные» такой фильтр не пройдут. А даже если и пройдут — быстро вылетят из системы, налаженной на эффективное производство результатов.
zharikovpro
16.10.2017 14:43> Вот есть люди, которые и за деньги и без денег вовсе будут делать правильно.
Можно назвать это культурой, можно назвать внутренней нематериальной мотивацией (в отличие от внешней материальной, например оплаты). Вообще нет противоречий, полный консенсус :)
areht
17.10.2017 05:06Не, культура — это наживное.
Научить людей делать хорошо может лет 5 занять. А попробуйте полгода поштрафовать тех, кто делает правильно за то, что делают правильно. Ну как штрафовать… Можно лишней работой «премировать».
krivotester Автор
17.10.2017 09:43+1Ахха, не я был инициатором, но наблюдать доводилось много раз.
Очень увлекательный опыт.
Главное открытие: никто не разбегается!
zharikovpro
16.10.2017 14:31P.S. Сам отношу себя к разработчикам высокой четкости (меткое выражение!). По мере развития скиллов все больше заинтересован в том, чтобы обе стороны работали на результат по принципу «поставленный продукт без дефектов = заработанные деньги».
Это устраняет кучу проблем с ведением проекта и выгодно обеим сторонам. Клиенту — т.к. он предсказуемо получает именно то что оплатил и мотивирует исполнителя на эффективность — максимально быструю выдачу запланированного результата. Исполнителю тоже хорошо, т.к. он получает бонусы за экспертизу и эффективное решение задач, а не за потраченные часы.krivotester Автор
16.10.2017 14:35+1С такими разрабами всегда приятно работать, хоть и сложно. Требует самодисциплины -)
zharikovpro
16.10.2017 14:40Почему сложно? Проанализировали задачу, спроектировали решение, реализовали, приняли (т.е. заказчик протестировал) — деньги в кассу пожалуйста, получите и распишитесь.
А без дисциплины со стороны заказчика никто из исполнителей классный результат не даст, имхо. Если кто лично знает контрпримеры — тому приз в студию!
ncix
17.10.2017 14:18-1За что разрабу платят, то он и делает.
Задача менеджера жестко пресекать подобное отношение к работе. Согласился работать — работай хорошо. Не устраивает зарплата — скажи. Всё равно не повышают — уходи.
zharikovpro
17.10.2017 15:07Подобное отношение к работе — самое честное и цивилизованное.
Понятие «хорошо» — субъективно. Представьте, интернет-провайдер предложит вам услугу с «хорошей» скоростью за «недорого» и скажет, что его менеджеры будут следить за тем, что скорость будет «хорошей», а цена — «приемлемой». Согласитесь подписать? Почему-то это не считается годным договором, прописывают скорость в Мб/с и оплату в рублях по тарифу т.д. и т.п. Аналогичная ситуация и с сотрудником, который предоставляет услугу нанимателю по договору.
Если к работе разработчика есть какие-то объективные требования — их стоит прописать в договоре, должностных инструкциях и т.д. и т.п. вместе с численными критериями и способами объективного измерения. Если это сделать не получается, значит критерий — либо опциональный, либо субъективный, либо и то и другое. Если критерий опциональный и/или субъективный — зачем вообще следить за его соблюдение и платить за это менеджеру и разработчику?
Важно ответить на вопрос «зачем» с точки зрения владельца бизнеса и в разрезе того, как выполнение условий увеличит прибыль компании. При тщательном исследовании вопроса ряд «требований» менеджеров оказывается не более чем их самоуправством и вкусовщиной из серии «я так вижу, я так хочу», густо замешанной на синдроме вахтера.ncix
17.10.2017 15:25Когда между работодателем и сотрудником отношения требуют столь подробного документального описания, когда для решения рабочих вопросов стороны апеллируют к пунктам трудового договора и должностных инструкций, на мой взгляд для обоих лучше расстаться.
zharikovpro
17.10.2017 15:30> Когда между работодателем и сотрудником отношения требуют столь подробного документального описания
Отношения между работодателем и сотрудником — не требуют. В вашем примере только менеджер что-то требует от разработчика. Почему, зачем, что такое «хорошо работай» — понятно примерно настолько же, насколько и ТЗ «сделайте нам классный сайт, чтобы было хорошо!»ncix
17.10.2017 15:45Вопрос на самом деле отличный. редко кто его поднимает, просто за время ИС сотрудник обычно понимает чего от него ждут. Если есть ощущение что сотрудник и руководитель по-разному понимают что значит "хорошо работать", нужно сесть вдвоем, обсудить и согласовать тезисно, чтобы это было принято обеими сторонами. Можно зафиксировать протоколом.
Если договориться не удалось, можно попробовать апеллировать к вышестоящему руководству или расстаться. Как-то так.zharikovpro
17.10.2017 15:59> просто за время ИС сотрудник обычно понимает чего от него ждут
Т.е. каждый новый сотрудник во время ИС вынужден методом проб и ошибок выяснять то, что в компании уже давно и так известно. Такой способ обучения сотрудников расточителен для компании.
Я осознаю, что все что я написал выше — крайне непопулярно. Точно так же, как и хорошо организованные, прибыльные, стабильно растущие бизнесы — большая редкость. Интуитивно чувствую тут корреляцию.ncix
17.10.2017 16:12+1Все зависит от размера бизнеса.
Если это энтерпрайз, там наврняка будут инструкции на все случаи жизни.
Маленькая компания — точно нет, и никто не скажет чего от сотрудника понадобится завтра.
Средние — где-то между этими крайностями. Если бизнес быстро растёт — в нём всё быстро меняется. В том числе меняются требования к сотрудникам.
Вопрос, в каком варианте конкретному человеку комфортнее. Я вот по себе знаю, что точно не хочу работать в компании где чётко прописаны инструкции на все случаи жизни. По мне лучше продуктивный хаос небольшой компании. Это интереснее.
zharikovpro
17.10.2017 16:29+1> Маленькая компания — точно нет, и никто не скажет чего от сотрудника понадобится завтра.
Именно поэтому странно пост-фактум требовать «делать хорошо» то, к чему еще вчера никто не был готов. В своих комментариях я возражал именно против такого сваливания ответственности с больной головы на здоровую, и только.
И т.к. в маленькой компании «никто не скажет что понадобится завтра» -именно поэтому там платят разрабам за «доступ к телу» в первую очередь, а далее — по ситуации, часто непредсказуемо.
Ну и конечно, все варианты жизнеспособны — выбирай на вкус.
Вот мы и подошли к логическому завершению дискуссии. Спасибо за конструктивный диалог!
zharikovpro
17.10.2017 16:09> Если есть ощущение что сотрудник и руководитель по-разному понимают что значит «хорошо работать», нужно сесть вдвоем, обсудить и согласовать тезисно, чтобы это было принято обеими сторонами. Можно зафиксировать протоколом.
Конструктивно! Предлагаю пойти дальше и на основании протокола исправить изначально дырявые договор и инструкцию, которые и допустили такую ситуацию. Тогда в будущем на решение тех же вопросов не придется тратить ресурсы почем зря.
zharikovpro
17.10.2017 15:09Считайте, что договор между работодателем и исполнителем описывает ТЗ и критерии приемки работы исполнителем. Без ТЗ закономерно получается ХЗ.
zharikovpro
17.10.2017 15:12> Согласился работать — работай хорошо.
Имхо, работать хорошо — это когда довольный клиент платит снова и снова. Программисту платит не менеджер, а заказчик. Поэтому и критерии «хорошей работы» — не менеджеру определять в первую очередь, а заказчику.ncix
17.10.2017 15:27Программисту платит работодатель а не заказчик. Заказчик может сегодня быть а завтра — нет, а зарплата остается. Поэтому работу программиста оценивает именно тот кто непосредственно платит ему деньги.
Кроме того, работа программиста как правило это лишь часть объема услуг, за который заказчик платит деньги.zharikovpro
17.10.2017 16:05> Программисту платит работодатель а не заказчик.
В этом случае работодатель и есть заказчик для программиста с точки зрения программиста, в коммерческом смысле слова.
Если труд программиста перепродается и есть т.н. внешний заказчик — он является прямым заказчиком для работодателя программиста и лишь косвенным для самого программиста. Такая иерархическая цепочка.
Клиент — полный синоним слова заказчик;
Покупатель — синоним слова заказчик;
> Кроме того, работа программиста как правило это лишь часть объема услуг, за который заказчик платит деньги.
А это не важно, мы же про программистов и их услуги говорим. Так вот программист оказывает на заказ именно услуги программирования. Тому кто за это платит.ncix
17.10.2017 16:19В этом случае работодатель и есть заказчик для программиста с точки зрения программиста, в коммерческом смысле слова.
Да, приходилось работать в компаниях, где между программистом и тем кто ставит ему задачи отношения были в духе заказчик-исполнитель. Где-то само так случилось, где-то, представьте, насаждалось искусственно! Кончалось всё тупиком. В конце концов "Заказчик" топал ногами, кричал, ругался, требовал. "Исполнитель" отбивался пунктами ТЗ, инструкций и pocker-face'ом. При этом оба получали стабильную зарплату а проекты тем временем затягивались на годы.
zharikovpro
17.10.2017 16:35> При этом оба получали стабильную зарплату а проекты тем временем затягивались на годы.
Это про бизнес и работу. Остальное — шелуха. Если заказчик «негодует» и продолжает платить исполнителю — значит его это устраивает.
В капитализме на свободном конкурентном рынке есть такая офигенная фишка, что если совсем не устраивают результаты работы одного исполнителя — просто меняешь его и платишь за то что устраивает. А за то что не устраивает — не платишь.
Описанная вами ситуация — точь в точь «мыши плакали, кололись, но продолжали жрать кактус». Ну, бывает — заказчики люди, могут вести себя иррационально.zharikovpro
17.10.2017 16:39P.S. Если заказчик не может уволить и заменить исполнителя — значит он и не заказчик вовсе. Кто может уволить исполнителя / разорвать договор / перестать платить за работу — тот и есть истинный заказчик для этого исполнителя.
ncix
17.10.2017 16:41Все верно, только есть ТК РФ, по которому ни уволить ни даже в деньгах прижать не получится без последствий. В нормальных коммерческих отношениях это рядовые инструменты взаимодействия заказчика с исполнителем.
zharikovpro
17.10.2017 16:46К сожалению, ТК РФ как и прочая бюрократия имеет мало общего с продуктивной работой.
Как организовать работу например ООО так, чтобы и продуктивно и по ТК РФ — организационный и юридический вопрос за пределами нашей дискуссии. Предполагаю, что при должной мотивации руководства это возможно. Но тут я некомпетентен и технических подробностей не знаю, легко могу ошибиться.
Из своего опыта скажу, что на фрилансе и при работе с ИП такой проблемы с ТК РФ точно нет.ncix
17.10.2017 16:56Из своего опыта скажу, что на фрилансе и при работе с ИП такой проблемы с ТК РФ точно нет.
Таких — точно нет, но есть другие. Заказчику нужно больше работы за меньше денег, исполнителю — наоборот. Фундаментальная мотивация разная. От этого уже конкретные проблемы растут. Но это уже совсем другая история.
zharikovpro
17.10.2017 17:00> Заказчику нужно больше работы за меньше денег, исполнителю — наоборот.
Так это в рыночных отношениях везде и всегда так, разве нет? Все ищут самые выгодные условиях. Т.е. ROI повыше — вложил поменьше, получил побольше.
И это не проблема, а стимул, благодаря которому конкурирующие исполнители замотивированы на повышение производительности труда. И благодаря конкуренции заказчик получает все лучшие и лучшие предложения. Это и двигает прогресс.
maxim_0_o
16.10.2017 14:32В голосовалке нужен еще вариант «Руководство не предоставляет ТЗ. Работаю на интуиции»
habradante
16.10.2017 15:05+3Я помню как-то давно обсуждал ТЗ с заказчиком по проекту. Обговорили функционал, описали в общих чертах. Потом я с командой обсудил, описал все технические моменты. В общем, все было весьма точно и без «тяп-ляп». Принес заказчику, он увидел, обрадовался. И я говорю:
— Ну что, подписываем и мы принимаемся за работу?
— Да, отлично! Если что-то еще изменится, я позвоню.
— Как изменится? Мы же уже ТЗ подписываем, на этом этапе уже ничего не должно меняться, будет реализовано как описано. Если вдруг что-то нужно будет, то мы готовы по доп. соглашению отдельно потом реализовать.
— Т.е. за дополнительные деньги?
— Конечно. Текущая стоимость покрывает только то, что описано в ТЗ.
— А вдруг я что-то упустил или мне надо будет что-нибудь поменять?
— Так для этого вы же и брали время на изучение ТЗ.
— Ну, я его изучал, но не с этой стороны. Там все, как-то, слишком досконально, я не вчитывался так глубоко. Может мы более общие моменты утвердим, чтобы, так сказать, иметь свободу в деталях?
С тех пор, сколько я ни смотрю на ТЗ, понимаю, что большинство, с обоих сторон, умышленно оставляют себе «свободу в деталях». И в ТЗ смотрят, когда либо проект очень большой и ответственный, либо хотят «продавить» контрагента.krivotester Автор
16.10.2017 16:27Я обычно «свободу в деталях» стараюсь выносить в отдельное приложение к договору за отдельную стоимость еще на стадии сметы.
В духе
— 100 часов на доработки?
— да!
— а не будет у нас доработок!
— точно?
— 100%
— договорились
ameli_anna_kate
16.10.2017 15:58У меня противоположенная проблема. Задача пришла в разработку, а потом все начинают менять ее. Тестировщику что-то не понравилось, он пошел обсуждать с менеджером, еще может влезть в спор пыха-разработчик. Дизайнер уступает и соглашается на изменения.
Посмотрело начальство, еще что-то велело поменять, и задача на выходе совсем не похожа на свое описание. Я стала говорить, что все желающие могут посмотреть макеты и высказаться дизайнеру, что их не устраивает, а если они этого не сделали, то их проблема, после отправки на тестирование ни какие изменения вне рамок макетов вноситься не будут. Что еще можно сделать?Kamas
16.10.2017 16:25Ходить по воде и разрабатывать программы согласно ТЗ очень просто, если они заморожены (с) E. Berard
krivotester Автор
16.10.2017 16:31Все-таки «все желающие» могут затянуть создание даже самого простого макета на годы. Нужно договориться, чтобы утверждением макета занимался один единственный человек.
Тогда можно записывать пакет правок, которые этот человек согласует в работу.
Это может быть: артдир, менеджер проекта, аккаунт и т.д., как договоритесь.
Если дизайнер будет ходить и собирать правки со всех, то когда же он будет рисовать? -)))ameli_anna_kate
16.10.2017 18:44Ах, если бы у нас за год сменилось порядка 6 менеджеров. Нежные они какие-то.
Приоритеты меняются чуть ли не каждые два дня.krivotester Автор
16.10.2017 20:32И как вам удается вообще как-то работать?
Ну разве что воспринимать промежутки между сменой власти как спринты -)ameli_anna_kate
16.10.2017 23:58Да вот по ходу предпоследнего я напугала. Все было норм, я возлагала большие надежды на девушку, она отработала полторы недели у нас и добралась побеседовать со мной. Я рассказала о проблемах, в основном про приоритетность задач, что все хотят свои задачи и срочно.
Пыха-программисты сделали какие-то своих задачи и требуют, что бы я дописала для них фронт, тестировщик что-то нашел и это тоже надо срочно фиксить. У маркетологов через три дня акция стартует, а у нас еще конь не валялся, начальство вообще хочет совсем другие задачи и тд и тд. Вот ей требовалось выслушать весь этот поток страждущих, разобраться, что действительно важно и скомандовать нам какие задачи, когда делаем, а какие пока откладываем. Там еще ряд моментов. Через пол часа узнали, что она решила уволиться.
Как работаем, ближе всего кан бан. Есть набор задач, выполняем из него, если что-то долгое, то делаем от нескольких дней или до нескольких недель, разбавляя процесс мелочовкой, занимающей от силы часик, полтора в день. Потом тестирование, еще ввели дизайнерскую приемку, они прямо в задачах подписывают, что принимают. Просто пищали, что не по макетам и жаловались начальству, что боятся ко мне подходить(сомнительное карьерное достижение, конечно).
Вообще мне нравится, что они принимают, порой глаз замылился, а они сразу видят, где отступ не совпадет или значок ниже, чем другие.
Еще случаются дни мелких задач, делаю дня два задач по 7-10 в каждый.
uniqm
16.10.2017 18:48Во-первых точно фиксировать в ТЗ изменения (всегда иметь актуальную версию того, что реально делают/сделали) + вести историю изменений(кто, на каком этапе, что и почему изменил) + вести трассировку с другими требованиями + следить за трудозатратами. Требования в целом вещь живая…
Разумеется меняем ТЗ если изменения разумны и состав менеджеров/клиентов это не вгонит в депрессию. Изменения согласуем с участниками, оглядываясь на трудозатраты и текущие правила игры.
И я вообще не верю, что в средней/большой задаче нужно прям 100% всего разжевать, это может быть не рационально по времени. В процессе реализации задачи на языке программирования в конкретном проекте всегда имеют место быть нюансы, которые «дешевле» бывает подогнать на месте глядя в текущий код. Разумеется речь не о фатальных промахах ;)
niko1aev
16.10.2017 16:244 года я был аналитиком и руководителем проектов.
И я считал свои ТЗ отличными и понятными. Я правда над этим много работал. Например, мне однажды попадалась подробная анкета на верстку от топового фрилансера на fl.ru, с 500+ положительными отзывами. Анкета состояла из 30+ пунктов поверх очень хороших макетов. Я из нее взял пунктов 10, и стал использовать на всех этапах, от ТЗ до приемки.
Но только став разработчиком, я понял, что все мои ТЗ были говно
Не в том плане, что неправильные. Просто не до конца проработанные. Конечно я и с ними добивался поставленных целей, но благодаря тому, что и дизайнеры и разработчики на своих этапах превносили в работу огромное количество полезных уточнений.
Например в ТЗ есть форма регистрации на 5 полей
99% ТЗ содержат перечень полей:
*Имя
*Email
День рождения
Телефон
Комментарий
Город
И поставив звездочки около имени и email заказчик, считает, что уже достаточно описал форму. И если есть moqups или дизайн формы — то вообще какие тут могут быть еще вопросы. А так как в его «сайте/портале/CRM/ERP...» таких форм десятки, а страниц десятки типов, то ТЗ уже и так на 50-100 страниц. А значит достаточно подробное)
Что же мы забыли
- Валидации полей на типы
- Валидации полей на лимиты (вряд ли 1800 год рождения — нормально)
- Валидации полей на уникальность (ну это же очевидно)
- Где проходит эта самая валидация(на сервере, или в браузере; понятно, что уникальность email мы не можем проверить в браузере, а вот желание проверять валидность и обязательность полей в браузере хорошо бы указать)
- Ошибки валидации (и даже если попросить их указать, вряд ли вы увидите две разные ошибки на невалидный email и уже существующий)
- А еще мы забыли уведомления на email, подтверждения телефона, восстановление пароля, авторизацию через соцсети и т.д. И каждый из этих пунктов — это формы, валидации, проверки, тексты ошибок, редиректы после успеха и неуспеха
- А еще самый коварный вопрос: при авторизации через соцсети, если пользователя с таким email нет, то отказывать в авторизации или создавать нового пользователя? А письмо ему на email в этом случае надо отправлять или нет?
99% заказчиков и 95% аналитиков неспособны на таком уровне проработать ТЗ
Заказчики не могут, потому что не понимают уровень детализации, и у них нет времени, а аналитики, потому что чаще всего это просто вчерашние секретари/секретарши, помощники/помощницы. Которые внезапно для себя делают сайт/портал и теперь пишут к нему ТЗ. Как умеют.
Какие из всего этого я сделал выводы для себя?
Неважно какую роль я играю: аналитик, заказчик, программист, руководитель проекта — если я вижу, что ТЗ содержит тонны подводных камней, я сажусь и вместе в диалоге его прорабатываю. Как с тем, кто является для меня заказчиком, так и с тем, кто является для меня исполнителем.
Нет никакого смысла отправлять заказчика доделывать ТЗ, со словами «ТЗ мутное». Он не будет его доделывать, а просто найдет того, кто будет с таким работать. Наступит на все грабли, и справедливо будет считать всех программистов козлами. А ведь у него был шанс, поработать с хорошим программистом, который поможет сделать ТЗ не мутным.
Также нет никакого смысла отдавать все на откуп разработчикам с мыслями: «Форма регистрации, табличка отзывов, страница профиля — это же так стандартно. Что тут может быть непонятно.» Разработчик в 99% сделает как он делал в прошлом проекте, или как принято в его стеке технологий, или как ему проще и нравится. Его «нравится» редко когда совпадает с чувством прекрасного у заказчика.
И нет никакого смысла вылизать сразу все ТЗ на 3ё500 страниц.
Мой рецепт:
- Разбить проекты на части
- Выбрать 1 часть. В начале желательно важную для проекта
- Детально описать
- Сделать 50%. Задать появившиеся вопросы
- Доделать, показать, получить правки, доделать
- Взять следующую часть
А еще очень важен постоянный диалог в стиле:
«Мы разбили проект/задачу на 7 частей. Первая часть займет неделю. Мы подготовили вопросы по ней. Сейчас проговорим детали.… (после того, как проговорили детали) Дня через три мы придем с новой порцией вопросов по первой части. А в начале следующей недели так же будем прорабатывать часть 2, подготовьте свои соображения, мы подготовим наши вопросы». И опять же это касается любого участника процесса: как заказчика, так и руководителя проекта, и тимлида, и разработчика, и дизайнера, и даже верстальщика.
Известно, что энтропия (в данном случае мера бардака в проекте) сама увеличивается, если не прикладывать осознанных усилий к её уменьшению. Так что помогают только осознанные усилия, диалоги, контроль, согласования, умелое отстаивание уже утвержденного, выкидывание лишнего. И только, если все это для уменьшения энтропии, а не снятия отвественности и оставления для себя свободы деталий и вариантов «нагнуть другую сторону»krivotester Автор
16.10.2017 16:35В целом я это называю: писать ТЗ так, чтобы разрабам хотелось его выполнить.
zharikovpro
16.10.2017 18:36Великолепный коммент!
В данном детальном описании еще забыли описать хранение служебных данных и структуру БД :)
Например, обычно полезно хранить дату регистрации пользователя. Модераторам, админу и бизнесу это нужно чтобы смотреть статистику регистраций, анализировать профили пользователей по когортам и т.п.
Решили что храним дату. Отлично, как в БД запишем — timestamp, timestamptz, в каком часовом поясе и т.п.? И ладно если речь про дату регистрации, это ДСП и в UTC все отлично.
А вот например в федеральном интернет-магазине нужно хранить дату и время доставки товара с учетом часового пояса и геолокации пользователя (см. раздел «Всё ещё хуже, чем кажется»). То же самое применимо к календарям-напоминалкам.
zenkz
16.10.2017 19:18У большинства ТЗ которые я видел есть одна или несколько из следующих проблем, из-за которых ими тяжело пользоваться:
1. Они слишком высокоуровневы и абстрактны, не учитывают многих деталей
2. Они плохо структурированы и их сложно читать
3. Они быстро устаревают и никто не заморачивается их обновлять (ни разработчик, ни аналитик)
Как я обычно работаю с ТЗ:
1. Читаю 1 раз (иногда по диагонали), чтобы понять что от меня хотят
2. Расписываю ТЗ в виде списка TODO задач с объёмом выполнения 0.5-1 день насколько это возможно. Обычно на данном этапе всплывает много непонятностей и неучтённых деталей, а также ограничений технологий
3. Разбираю все непонятности с аналитиком и дополняю свой TODO лист
4. Реализую по списку (позволяет не пропустить мелочей)
5. В ходе тестирования опять обсуждаем детали с тестировщиком и аналитиком.
Как решить проблемы ТЗ:
1. Аналитик должен «владеть» ТЗ. Т.е. поддерживать его в актуальном состоянии. Из этого следует, что аналитик всегда должен быть в курсе изменений
2. Для разработчика ТЗ более удобен не в виде формального документа, а в виде списка задач в таблице
3. Аналитик должен проводить подобие UAT после окончания разработки, чтобы убедиться что сделали то, что хотел заказчик.
4. Тестировщик с аналитиком пишут чёткие сценарии тестирования (желательно ещё до начала разработки)
zharikovpro
17.10.2017 13:20> Тестировщик с аналитиком пишут чёткие сценарии тестирования
Лучше когда сценарии приемки вмсте пишут и согласовывают клиент и аналитик. Т.к. в конечном итоге принимать работу будет клиент.
CheY
16.10.2017 20:33Уже 5+ лет занимаюсь работой аналитика. Поработал с разработчиками от разных «полюсов»: как с теми, которые будут докапываться до каждой фразы, причём не стесняясь в выражениях и зачастую с большой долей высокомерия, так и с теми, которым ТЗ не нужен — достаточно постановки и времени на обсуждение.
Особая острота к работе добавляется, когда у тебя есть определённые компетенции в разработке, особенно в используемом в работе стеке. Как экстремальная форма ситуации — когда разработчики настолько плохи, что даже ты со своими «домашними проектами» их превосходишь в их области (при аутсорсе встречались такие). С одной стороны это огромный плюс — ты способен оценить сложность реализации того, что ты описываешь, ещё до оценки разработчиками, ты знаешь какие вещи реализуемы, какие сложнореализуемы, а какие просто невозможны, ты знаешь, где что-то может пойти не так и где требуется уточнение поведения. С другой стороны, ты «всего лишь» аналитик — большинство разработчиков встретит вторжение в сферу своей ответственности от тебя со скепсисом (осторожностью/враждебностью/возмущением). В итоге приходится постоянно лавировать между «тем, что ты знаешь» и «тем, что от тебя ждут», зарабатывать доверие разработчиков и бороться с внутренним конфликтом «брошу всё уйду в разработчики». К сожалению, это очень распространённая проблема разработчиков — недоверие к опыту не-разработчиков. Впрочем, объяснимая — аналитиков, которые пишут совершенно поверхностные ТЗ очень много.
Для себя я решил, что идеальная работа — это работа с командой, которая прежде всего всегда готова к обсуждению и готова к свободе своих действий в обмен на риск что-то выбросить и переписать. Можно называть это agile, можно lean, можно даже «пиши код бл*ть» — в любом случае нужно принять возникновение ошибок как что-то неотвратимое и постараться сэкономить время на попытках их предотвратить, потратив это время на создание функциональности. Ну, и мотивация всех на конечный результат, а не закрытие тасков в трекере. Пусть даже внутренняя.
boblenin
17.10.2017 04:33Может быть не так уж и нужно это самое соответствие ТЗ. Часто бывает так, что к моменту когда ТЗ дописано — оно уже устаревает. Да что там ТЗ, даже просто требования. Ну сделали вы все строго по ТЗ, а клиенту продукт в том виде в котором он был актуален ранее — уже не подходит. В конечном итоге задача у вас и у клиента заработать денег, а не заниматься крючкотворчеством.
qmax
17.10.2017 10:57Мой свой вариант: пишу ТЗ, которые никто не читает. Даже заказчик.
Надо попробовать оформлять сценарии юзкейсов в виде комиксов. И чтобы в последнем кадре персонаж направлял вопросительный взгляд на читающего.krivotester Автор
17.10.2017 11:21Если к заказчику активно не приставать, он и не будет читать ТЗ.
А потом скажет, ой, я это первый раз вижу.qmax
17.10.2017 12:48Заказчик может свято верить в магию технологий и колдунство программистов.
Такую веру не просто разрушить просто активными приставаниями.
amarao
17.10.2017 12:54Эм… тесты? Написал тесты, прогоняешь код. Если ТЗ неалгоритмизируемо или его трудно проверить — надо менять ТЗ, точнее, переформулировать так, чтобы можно было.
krivotester Автор
17.10.2017 13:34Из чеклиста в ТЗ:
n: Должны быть подписи осей на всех графиках.
Тест: Есть подписи или нет?amarao
17.10.2017 13:46(опуская детали реализации):
def test_plot_signature_x(...): graph = fixture_to_create_graph() assert len(graph.g.plot.axis_x.text) > 0 def test_plot_signature_y(...): graph = fixture_to_create_graph() assert len(graph.g.plot.axis_y.text) > 0
Это требует графика в машиночитаемом формате, разумеется, и соблюдения конвенций по именованию объектов в svg.
Именно это я и называю «менять ТЗ».
Вместо «должны быть подписи на графиках» — график должен быть в формате svg, в объекте g в объекте plot, для которого должны быть заданы объекты axis_x для горизонтальной оси и axis_y для вертиальной. Обе оси должны иметь текстовое описание в поле text соответствующего объекта axis_*.
Хорошо написанное ТЗ — половина теста. Хорошо написанный тест — половина программы.
Вот так вот написав 25% программы можно более-менее быть уверенным что программа на 100% хороша.krivotester Автор
17.10.2017 13:58+2Часто ли вы получали такие ТЗ от живых клиентов или заказчиков? -)
amarao
17.10.2017 16:13А не для этого ли нам аналитики?
Алсо, получали. Машиночитаемость взаимодейтсвия с заказчиком — очень частое требование.
YetAnotherSlava
17.10.2017 14:28Многие разработчики когда-то прорешивали SICP и занимались собственными проектами, вылизывая их.
А потом пошли работать, и поняли, что платят — за говнокод, главное чтобы его было побольше и в срок. И еще — нужно свалить с проекта раньше, чем он начнёт реально использоваться.
Сначала человек читает Рихтера, у которого всё написано по делу. Потом сталкивается с чьими-то хотелками, пожеланиями людей, которые не в состоянии выражовывать свои мысли в письменном виде, но почему-то имеют и аттестат, и диплом, и даже деньги. Разумеется, половину того, что эти люди выражают, приходится отфильтровывать. А если не фильтровать — за это больше не заплатят, но сил останется меньше, чем у бодро кидающих лопатой говнокод и хорошо социализированных коллег.
evgenWebm
17.10.2017 22:51ТЗ? Что такое ТЗ?
Я один раз добился ТЗ. Прислали на почту. Думаю ура.
Открываю, а там… я незнаю как это назвать, но если я делал бы по ТЗ, то явно получилось что угодно, кроме заказанного.
Оказывается, писать ТЗ реально для слабаков. Интернет поможет. Чужой ТЗ, пару страниц правок, а дальше зачем? Получай и делай)))
Jef239
19.10.2017 02:01Если заказчик любимый — делаем то, что ему нужно.
Если заказчик нормальный — делаем то, что он хочет.
А если заказчик мерзкий — делаем то, что он написал в ТЗ.
Был случай год назад — сделали по ТЗ. Написано «web-технологии» — ставим клиента на web-технологиях. Ну и что, что он readonly, ввод из клиента в ТЗ не прописан. Ну значит данные вводятся с сервера, с клиента — только наблюдение за процессом.
Выяснилось это все на этапе пусконаладки за 3 дня до сдачи испытаний. В медвежьем углу Волго-Балта. Мда, настолько багрового клиента я ещё никогда не видел. Нам повезло — инфаркта у клиента не было.
Да, баг не наш — мы просто сделали по ТЗ. Но все равно — дичайший ляп. Пришлось сдавать через RDP, а потом переделывать.
Таких историй довольно много. Ибо ТЗ не застрахован от багов.
Вся беда в том, что ТЗ надо тестировать. Но заметить ошибку на этапе ТЗ — сложнее, чем на этапе отладки. И написание и тестирование ТЗ требует высокой квалификации.
Так что исправлять баги на отладке — дорого, а добиваться качественного ТЗ тоже дорого.
Ну в общем см. рис 1
krivotester Автор
19.10.2017 13:45Да это очень важный момент. Когда вы получили подписанное ТЗ, а в нем чушь, если сделать чушь, то заказчик считает, что виноваты все равно вы. Ну не всякий конечно так считает, но часто, да.
Я люблю проговорить и с заказчиком и с разработчиком голосом каждую строчку. Хоть все от этого морщатся, но часто такие моменты нащупать позволяет до поездки в медвежий угол -)Jef239
19.10.2017 20:37Беда в том, что мы не поняли, что это была чушь. Потому и не уточнили.
krivotester Автор
19.10.2017 23:39Допускаю, такое и со мой бывало, но не в таких масштабах конечно.
Никто не застрахован -(
shuvaevgl
По этому поводу есть характерный анекдот.
— Что надо сделать для того чтобы спутники успешно выходили на орбиту?
— Отправлять их туда вместе с их разработчиками.