Comments 48
Рыба всегда того... С головы.
Вписаться в проект, взяв обязательства по срокам и неустойкам, и взяться писать код, не имея на руках ТЗ, но получая новые правки по макету не двигая при этом сроки... По-моему, там всё безнадежно еще на старте было.
Ну при работе с госами это типичная ситуация. Опытные люди закладывают х3 для госов от коммерческих заказчиков. Не потому что госы богатые, а потому что вот эти изменения и трактовки ТЗ это все переделать заново пару раз
Я с госами, давно работал и не по IT, воспоминания наоборот о полной дебильности в чрезмерной точности ТЗ.
Помню взяли контракт забор построить, они потребовали прописать количество опор, там была цифра типа 3600 опор. Когда они делали приёмку, трижды отправляли людей чтоб посчитать опоры, а там километров 40 было, в итоге не хватило 4-х, орали, что мы хотим их обмануть. В итоге в самом дальнем месте вкопали ещё 8 опор, просто так, без этого акт приёмки не подписывали.
Ps. Забор упал через год, но всем было пох.
орали, что мы хотим их обмануть
Э.. ну вписали бы в акт приемки реальное количество опор. Чтобы была бумага *опу прикрыть. Ну, и раз прописаны формальные требования - почему бы их не соблюдать?
Забор упал через год
Все 40 км??
Хуже. Рядом с проходной) По лесу то пофиг пусть хоть весь падает) А тут прям на глазах у заказчиков)
Если заказчик тупой, то проще поставить 4 столба, чем объяснить почему нет. Там ещё целая история, как их считали, там реально 40 км по условно проходимой местности. Было штук 8 подсчётов и ни разу цифры не совпали. Потом пронумеровали всё столбы.
Странно, что сразу не пронумеровали.
Хотя бы каждый десятый, например.
Если заказчик тупой, то проще поставить 4 столба, чем объяснить почему нет
Так забор упал потому что заказчик тупой или, всё-таки, потому что исполнители криворукие будет распилили и даже столбы на дачку уволокли?
Конечно заказчик. Исполнители в РФ традиционно святые.
6000км волочить на дачку неудобно.
Падение забора, и бюрократия с 4столбами - это две разные проблемы.
Особенно не воровали, строили в сложных условиях, тупо была проблема Бетон купить за любые деньги, может сэкономили + аномальный ливень+гос тендер по минимальной цене.
биба заказал,а боба "исполнил")
Работал с госами в полиграфии - согласен с каждой строчкой. Есть некоторые "бывалые" они говорят - требования будут вот такие по тому что так надо, но по факту мы будем делать вот так, по тому что мы не сумасшедшие. Но "в среднем по больнице" удовольствие очень и очень сомнительное
Интересно, прокатил бы вариант "3600 опор, погрешность измерения количества опор +-0.5%".
Угу, как столбы меряли? Мужичок, говорите, бегал считал? А мужичок-то поверенный? Нет? Вот и погрешность образовалась
Это специфика законодательства о госзакупках. Техническое задание является частью контракта и фиксируется при объявлении закупочной процедуры. Заказчик не имеет права менять условия договора в сторону уменьшения работ. Это же очевидный способ коррупции. Подрядиться построить 40 км забора, на этапе закрытия договора согласиться что построено только 4 км. Допускается только изменение договора в сторону увеличения объема работ при сохранении суммы оплаты.
Поэтому Ваши Заказчики просто хотели защититься от возможных штрафов при проверке или, маловероятно, но уголовной ответственности. Зачем завхозу или другому госслужащему, принимающему работы, рисковать попать на штраф 30-50 тыс. рублей?
Удивляет негативная коннотация при упоминании заказчика. Все же партнеры по бизнесу, платящие Вам деньги заслуживают уважения. Они не нарушали закон, не требовали взяток. Они требовали точного соблюдения подписанного Вашей стороной контракта.
Верно, это нормальная ситуация когда компания работает с проверенным, надежным, заказчиком и сами госы доверяют исполнителю, но в данном случае у них всё было "в первый раз".
А как в одностороннем порядке изменить ТЗ по подписанному договору, мне вот интересно?
Много ли видели госзаказов с финальным ТЗ?
В моей практике там обычно написано "Всё должно работать. Детали что всё, и как будет согласовано в рабочем порке в виде протоколов". И тут уже дело менеджмента себя проявить, как не взять на себя лишнего но и не позлить заказчика.
Была помню история, в далеком 13 году, когда ко мне подкатили учредители похожей конторы, занимавшейся аутсорсом по гос. контрактам мол есть хороший контракт, аж на 2М, делов то сделать небольшой биллинг. Пошел смотреть, заказчик минобороны, небольшой биллинг реальности полномасштабный бэкенд для полигона то ли Г3, то ли Г4, правда я так и не понял, при чем тут минобороны. В общшем покрутил пальцем у виска, мол вы вообще в своем уме, вписываться в такое без готовой системы, расчитывая написать ее с нуля. Не говорят все пучком, мы им типа прототип наговнякаем, а потом уже дороботки, в общем послал их. А потом как то пропали они с радаров, может где то отсижывают продолбанный контракт.
На руках у нас появилось первое "финальное ТЗ".
Наша команда утопает в правках, каждую неделю нам спускают пачку "хотелок", и мы послушно начинаем их реализовывать.
Ошибка в реализации "хотелок" не указанных в "финальное ТЗ".
Реализация по ТЗ: прикрывает разработчика (исполнителя) от "хотелок".
Нет в ТЗ - нет в проде.
ЕГРН вообще пилили с помощью той самой матери. Казалось бы, заказчик весьма влиятельная контора, даже ТЗ было. Но вот зачем-то не выдрали из исполнителей, например, ПК ИС «Юстиция» и ЕГРП (тех, кто предыдущие итерации пилил), схем раскладки данных в базах. В итоге объекты мигрировали почти поштучно, вылавливая отдельные случаи и складируя это в портянки CASE / if.
В таких ситуациях очень многое зависит от руководства, потому что иногда даже хорошее техническое задание не спасает от плохих результатов, как и старания разработчиков.
Очень хорошо, когда такие статьи публикуются - для начинающих руководителей это хорошая возможность взглянуть на проблемы выполнения проектов (в данном случае - госконтрактов) с другой стороны - со стороны исполнителя.
Поделюсь и своим опытом) У меня была подобная ситуация с одним госконтрактом (не успешное его выполнение). К тому проекту я подключился за 1.5 недели до его фактической сдачи заказчику. Срок на разработку был 3 месяца, техническое задание было составлено хорошо (система для мониторинга), даже макеты дизайна предоставили (на что ориентироваться). Не совсем понятно чем разработчики занимались всё время выполнения этого контракта, как и непонятно что делало в это время руководство. Не сложилось обратной связи у исполнителей и руководителей, подобная проблема очень часто возникает в компаниях, которые разрабатывают не цельный продукт, а множество мелких или не очень мелких заказов ("конвейерные компании"). В таких компаниях, как правило, не складываются сильные команды (хотя бывают и исключения), потому что специалистов очень быстро нанимают, ну и также быстро увольняют :)
Проектом занимались разработчики, которые с Битриксом познакомились буквально в тот момент, когда этот контракт их компания взяла (т.е. с самого начала опыта работы с Битриксом ни у кого не было). Привлечь эксперта со стороны руководители и не собирались, решили что здесь можно обойтись своими усилиями (спойлер: они ошибались).
Как только я подключился к данному проекту в роли тимлида, я осознал, что закрыть заказ не получится (чтоб было понятно - было сделано очень мало, дизайн был готов на ~40%, а вёрстка в Битриксе - на ~30%), поэтому я сфокусировался на достижении минимального результата чтобы компания не платила неустойку и не банили её в реестре исполнителей на 1 год. Благо в самом контракте был прописан этот "минимум", реализовав который можно было обойти некоторые санкции. Думаю, что в такой ситуации это оптимальная цель, потому что достичь полного выполнения 3-х месячного госконтракта за 1.5 недели задача крайне трудная (если совсем не выполнимая).
Ну и, собственно, удалось наладить контакт с командой и мотивировать её доделать этот проект хотя бы на "минимум", не говоря уже о полном завершении проекта. И за неделю, с привлечением множества фронтендеров (которые также не работали с Битриксом ранее) с других проектов (а некоторые были моими хорошими знакомыми) мы успешно сверстали все страницы по макетам и сделанному на скорую руку дизайну и даже добавили кое-какой бизнес-логики, чтобы сайт не был уж совсем статичным)
По итогу было сделано примерно ~90% (~90% дизайн, ~90% проект на Битриксе) всей работы над проектом за эти 1.5 недели. Конечно, я не "супер тимлид", ни в коем случае, просто с командой сложились доверительные отношения и мы нашли общий язык, благодаря чему смогли "дотащить" этот проект до финишной прямой) Как итог: компания не платила за неустойку и не была исключена из реестра исполнителей.
Очень многое зависит от руководителя. Я не раз наблюдал, как проекты истощаются только из-за того, что их руководитель на них просто "забивал" и только перед дедлайном "просыпался" и удивлялся "что же здесь не так? Где результаты?".
Хороший руководитель может сделать так, что даже самый неудачный или слабый проект станет чем-то особенным, а вот плохой наоборот - может "уничтожить" даже самый амбициозный и крутой проект.
Был проект по госконтракту длиной в год. Перед началом работ было составлено тз пунктов на 10. Принялись делать. На третий месяц была первая встреча с заказчиками. По результатам этой встречи оказалось, что то, что они хотят, и то, что написано в тз, имеют мало чего общего. Вся суть проекта свелась к одному пункту из дополнительного соглашения к тз, который настолько всё менял, что предыдущие наработки оказались мало полезными. А потом ещё в конце пришлось отчитываться по тз, хотя у проекта с оригинальным тз было мало общего.
Не вижу по тексту поэтому спрошу: за все время разработки, показывали ли вы то что получается (демо) заказчику или его представителям (тем, кто понимает, что нужно и за чем)?
Если да - на каких этапах и как часто?
Если нет - почему?
Спрашиваю, потому как это могло решить часть проблем.
показывали ли вы то что получается (демо) заказчику или его представителям (тем, кто понимает, что нужно и за чем)?
Строго говоря, это не дело разработчиков ни в коем виде. Это дело ПМа. А ПМ там явно факапил с самого начала до самого отнюдь не победного конца.
Я понимаю. Просто получается, что ваш манагер не узнал ни куда нужно грести, ни докладывал заказчику куда вы плывете. С другой стороны, вы, как девелопер, выбрали, что ваше дело чисто грести и старались грести лучше, что бы все исправить. Получается, что в этом случае не так и удивительно, что лодка приплыла не туда.
Такая ситуация встречается куда чаще, чем хотелось бы. Заказчики бывает не знают чего хотят, а манагеры бывает не знают как решать проблемы.
Вы ясное дело не обязаны разгребать эти дебри. Но практика показывает, что инженер может это решить. Рассмотрите следующий раз просто вариант самостоятельного налаживания полного цыкла контактов и обратной связи. Это решит много проблем упомянутых в статье. Это даст вам опыт, возможно денег и авторитет человека, который может решить вопрос/проблему.
Это может пригодиться. Ибе кейсов у вас таких будет еще не мало.
П.С. Я не в коем случае не осуждаю. Я просто сам так раньше думал. Но в итоге так и не дождавшись тех, кто должен эти вопросы решать так, как я считаю правильным - я начал их решать сам. И оказалось, что это (внимание) тоже интересно даже "полным" девам, сложно, полезно и расширяет горизонты понимания/возможностей.
Просто рассмотрите следующий раз возможность взять ситуацию под свой контроль.
@AlekseyPraskovinпрошу прощения, я спутал вас с автором статьи. Так что мой второй комментарий не к вам и автор уже по теме ответил ниже. Чего то я маху дал и все попутал :(
Автор уже сказал, что нечто подобное и пытались делать, но тоже не вышло.
Выглядит так что у заказчика даже не могли спросить что ему нужно ;)
Да, показывали результаты примерно раз в одну, две недели. Оттуда и было море правок и хотелок. Как сказали манагеры «старались удержать лояльность заказчика». Ребята хотели угодить и не упустить возможность получить дальнейший контракт на поддержку. В итоге ставка не сыграла
Это косяк проектного управления в чистом виде, ПМ просто не умел работать с госами и заключать с ними контракты, ну и вообще - в проекте сломан scope бюджет и сроки.
Форвардииь требования заказчика исполнителям - это не управление проектом, доработки надо выносить за scope и уметь продавать отдельно
Это точно не ваш косяк
Сколько раз от госов прилетал фидбэк начальству, что я недоговороспособный, когда на чернуху продавить не могли -- не перечесть. Но зато задница оставалась целой у конторы по моему направлению.
В общем и целом, не вижу в этой ситуации ничего плохого. Автор "хлебнул жизни" без видимых проблем. В смысле, не попал на деньги и не угробил здоровье. Зато получил хороший опыт и узнал, что такое тоже бывает. И когда, на следующем месте работы увидит тревожные звоночки, то уже точно будет понимать, к чему это все приведет
Ой, читаю и вспоминаю свой первый проект, куда меня взяли фулл стеком без опыта))) Все точь в точь, нет никакого ТЗ, я все делаю по хотелкам директора. Промчался месяц, вроде норм. Идём на сдачу , тип который принимает приложуху, смотрит на нас с недоумением, и говорит что все фигня переделывайте. На вопросы по ТЗ , меня благополучно посылают))) Ещё 3 месяца хотелок и исправлений. Вроде ок . И тут.... ПРИХОДИТ ЧЕЛОВЕК КОТОРЫЙ БУДЕТ С ЭТИМ РАБОТАТЬ И ГОВОРИТ ЧТО ЭТО ВООБЩЕ НЕ ТО ... В общем много я с этим намечался. Закончилось все тем, что мы 3 января сдавали под подпись приложение пьяному директору по производству )))
Кабаныч, видимо, тертый калач и сразу правильно определил виновных: Сначала директор дивизиона, затем ПМ. Такой большой проект, даже если его целиком вел ПМ, должен контролироваться директором дивизиона. Тимлида судя по всему давно надо было выгнать и это тоже решение ДД. У меня госы основной заказчик (несколько в другом направлении) и в такие заказы вписываться можно (особенно если платят хорошо, а судя по описанию контракт должен был быть выгодным) но как минимум:
1. Все общение с заказчиком только в письменном виде. Так у нас есть возможность спихнуть вину за сдвиг сроков на неопределенность заказчика.
2. Все изменения пытаться закреплять юридически, т.е. делать доп. соглашения к контракту. Обязательно со сдвигом сроков. Не факт что получится, но если не получится - у нас есть аргумент что-бы отказаться.
3. Ну и очевидное - сначала делать основной функционал по основному ТЗ (каким бы оно ни было, принимать будут по нему), а потом уже изменения и дополнения.
Всё в лучших торадициях, с использованием передовых практик в управлении коллективом.
Сколько статей было и рекомендаций. Ничего не поменялось особо.
Виновато низкая квалификация людей, которые доводят задачи до разработки, к сожалению так почти всегда:(
Каким образом может быть заключен госконтракт без изначального, он же и финальный, ТЗ на систему?
Госконтракт: история о том, как мы не справились