Comments 60
«Слезы радости» застили глаза после прочтения. Полезно знать, что род подобных заказчиков не только занимается недвижимостью и доставкой грузов, а и пробует себя в медицине. Дас, все грустно.
Я бы вообще не стал работать с государственными организациями.
Для меня это как табу.
Странно, что некоторые себе позволяют видеть «Роснац...» в виде «заказчика».
Шли бы они в пень, себе потом будет дороже с такими работать.
Слишком много вокруг примеров, господа.
Для меня это как табу.
Странно, что некоторые себе позволяют видеть «Роснац...» в виде «заказчика».
Шли бы они в пень, себе потом будет дороже с такими работать.
Слишком много вокруг примеров, господа.
Это не государственный заказчик. Это какая-то мутная «ассоциация» с названием, похожим на что-то «государственное».
Да тем более.
Мы столько секса поимели с «интерсекьюритифорум», что никому такого не пожелаю.
Оно даже гуглится — можете посмотреть.
Всё, что косит под государственную структуру, всё, что в составе заказчиков имеет государственные структуры — ровным строем идёт в пень.
Иначе, у вас будет секс на каждом этапе согласования, создания и внедрения.
Проще частникам сделать интернет-магазин керамической плитки.
Мы столько секса поимели с «интерсекьюритифорум», что никому такого не пожелаю.
Оно даже гуглится — можете посмотреть.
Всё, что косит под государственную структуру, всё, что в составе заказчиков имеет государственные структуры — ровным строем идёт в пень.
Иначе, у вас будет секс на каждом этапе согласования, создания и внедрения.
Проще частникам сделать интернет-магазин керамической плитки.
Да и среди негосударственных таких миллион. Но как по мне, тут и разработчик наделал ошибок со своей стороны. Заказчику-то несложно сказать «а давайте всё переделаем нафиг». Но разработчик в ответ на это не должен всё переделывать нафиг (ещё и без увеличения сметы), а объяснить заказчику, сколько и почему это ему будет стоить, и по деньгам, и по срокам.
А ещё, пункт о разрешении таких ситуаций (а-ля «в случае изменений уже разработанного функционала такие работы выполняются как дополнительные, за отдельную плату»). необходимо изначально включать в договор с заказчиком. Благо, он обычно даже с самыми сложными заказчиками не вызывает вопросов.
А ещё, пункт о разрешении таких ситуаций (а-ля «в случае изменений уже разработанного функционала такие работы выполняются как дополнительные, за отдельную плату»). необходимо изначально включать в договор с заказчиком. Благо, он обычно даже с самыми сложными заказчиками не вызывает вопросов.
«Если вы не любите людей — значить вы просто не умеете их готовить»(с)Людоед.
Нет, государственный заказчик — это особенный заказчик типа «араб», к которому нужен особенный подход. Особенность в том, что с ним ни в коем случае не надо пытаться «дружить», надеясь на дальнейшее сотрудничество и партнёрство (ибо сами знаете насчёт страны...), а стараться брать оплату за каждый взбрык. Переделка макета — столько-то, реализация идеи — столько-то, реализация глупой идеи — в двойном размере, ложный вызов менеджера по работе с клиентами — гоните оплату, барин. Итоговый проект не взлетит с вероятностью 90%, это нужно просто принять как данность. Но главное — самим в пролёте не остаться по деньгам.
Нет, государственный заказчик — это особенный заказчик типа «араб», к которому нужен особенный подход. Особенность в том, что с ним ни в коем случае не надо пытаться «дружить», надеясь на дальнейшее сотрудничество и партнёрство (ибо сами знаете насчёт страны...), а стараться брать оплату за каждый взбрык. Переделка макета — столько-то, реализация идеи — столько-то, реализация глупой идеи — в двойном размере, ложный вызов менеджера по работе с клиентами — гоните оплату, барин. Итоговый проект не взлетит с вероятностью 90%, это нужно просто принять как данность. Но главное — самим в пролёте не остаться по деньгам.
Тут нужно понимать специфику.
У этих людей нет ни капли заинтересованности в выпуске продукта. Большие дяди собрались и решили запилить проект, выбили бюджет и спустили задачу более мелким дядям (задачу спустили а цели, что важно, так и остались в голове у больших дядь, если вообще не были забыты).
А далее стандартный сценарий — есть бюджет, есть задачи и есть люди, которым сказано копать от забора до обеда они и капают от забора до обеда. Их главная цель (если не разводить холивары про откаты) — соблюдать спущенные с верху сроки и деньги + получать ЗП. Интереса в запуске продукта уже нет.
Тоесть если Вы хотите заработать относительно легкие деньги и у вас команда чуть ниже среднего (там явно не нужны супер звездная команда разработки, дизайнеры от бога или не спящие ночами продакт овнеры) велкам на тендеры к гос сектору или внутренние проекты крупных корпораций (там примерно творится тоже самое что и в гос структурах)
У этих людей нет ни капли заинтересованности в выпуске продукта. Большие дяди собрались и решили запилить проект, выбили бюджет и спустили задачу более мелким дядям (задачу спустили а цели, что важно, так и остались в голове у больших дядь, если вообще не были забыты).
А далее стандартный сценарий — есть бюджет, есть задачи и есть люди, которым сказано копать от забора до обеда они и капают от забора до обеда. Их главная цель (если не разводить холивары про откаты) — соблюдать спущенные с верху сроки и деньги + получать ЗП. Интереса в запуске продукта уже нет.
Тоесть если Вы хотите заработать относительно легкие деньги и у вас команда чуть ниже среднего (там явно не нужны супер звездная команда разработки, дизайнеры от бога или не спящие ночами продакт овнеры) велкам на тендеры к гос сектору или внутренние проекты крупных корпораций (там примерно творится тоже самое что и в гос структурах)
1. От постоянных правок помогают гибкие методологии. А вы, похоже, решили всё и сразу задизайнить, а потом реализовать.
2. Не совсем понятна ваша роль. За что отвечали в проекте?
2. Не совсем понятна ваша роль. За что отвечали в проекте?
Можно узнать подробнее про гибкую методологию? Мы сначала сделали кучу прототипов, а потом дизайн.
Я и проджект и дизайнер проекта
Я и проджект и дизайнер проекта
https://ru.wikipedia.org/wiki/Гибкая_методология_разработки
Исходя из вопроса, я начинаю догадываться о причинах описанного развития проекта.
Исходя из вопроса, я начинаю догадываться о причинах описанного развития проекта.
Собственно, статья не просто про провал проекта, а про некомпетентность всех сторон — и прежде всего, автора статьи.
Очень интересно на чем основан ваш аргумент? В каком месте мы были некомпетентны? Все было в срок, соответствовало все ТЗ, все этапы были согласованы. А оценивать уровень компетентности по постоянным доработкам заказчика, это как-то… глупо
Есть такое понятие: управление ожиданиями заказчика. И вот тут вы похоже не справились, как ПМ. Потому как работа ПМ, в том числе, заключается в том, чтобы предложить такой подход, который бы учитывал постоянные правки. Я не зря упомянул гибкие методологии. Они действительно могут помочь. И когда человек, который называет себя ПМ, с одной стороны, спрашивает: что это такое, agile? А с другой стороны, сваливает неудачу проекта на заказчика, который постоянно приносит правки, возникают резонные сомнения в его компетентности.
Ну в статье написано, что на все наши идеи были категоричные отказы. Какое бы вы решение могли предложить?
Гибкие методики это не серебренная пуля, они никак не помогут при работе с заказчиков вида — а давайте все переделаем. Вы неделю пилите пачку мелких функциональностей, а на следующем совещании вам говорят — вы ничего из того, о чем мы договаривались не сделали, мы обратимся в другую компанию, а с вами посоветуем никому дел не иметь.
В данном случае только метод «каждая работа должна оплачиваться» без попыток «подружиться» с клиентом.
В данном случае только метод «каждая работа должна оплачиваться» без попыток «подружиться» с клиентом.
1.
Да, согласен, agile — не серебряная пуля. Но, он может сильно помочь в описанной ситуации, если уметь им пользоваться.
2.
Они как раз на такое и рассчитаны. Закончили спринт (допустим, здесь и далее у нас Scrum). А дальше — хоть с нуля, хоть переноси с веб на десктоп. Главное, спланировать на следующий спринт.
3.
«Гибкая методология» — не равно «отсутствие требований, плана и т.п.». Нельзя работу работать в спринте и в итоге сделать не то, что было поставлено, как цели на спринт, а что-то другое. И договорённости все фиксируются. И закзачик сам принимает участие в определении целей.
4.
Одно другому не мешает. Работа должна быть оплачена всегда.
Гибкие методики это не серебренная пуля
Да, согласен, agile — не серебряная пуля. Но, он может сильно помочь в описанной ситуации, если уметь им пользоваться.
2.
они никак не помогут при работе с заказчиков вида — а давайте все переделаем.
Они как раз на такое и рассчитаны. Закончили спринт (допустим, здесь и далее у нас Scrum). А дальше — хоть с нуля, хоть переноси с веб на десктоп. Главное, спланировать на следующий спринт.
3.
Вы неделю пилите пачку мелких функциональностей, а на следующем совещании вам говорят — вы ничего из того, о чем мы договаривались не сделали, мы обратимся в другую компанию, а с вами посоветуем никому дел не иметь.
«Гибкая методология» — не равно «отсутствие требований, плана и т.п.». Нельзя работу работать в спринте и в итоге сделать не то, что было поставлено, как цели на спринт, а что-то другое. И договорённости все фиксируются. И закзачик сам принимает участие в определении целей.
4.
В данном случае только метод «каждая работа должна оплачиваться» без попыток «подружиться» с клиентом.
Одно другому не мешает. Работа должна быть оплачена всегда.
На доработки заказчика можно соглашаться только с подписанным Change Order. Все остальное (включая чаты, емейлы, личные разговоры) — это не документы, к делу не подошьешь. Соглашаться на доработки бесплатно и не задокументированно — путь к закономерному провалу.
С девятого абзаца и далее везде.
Вот это неправильно. В любой момент времени у вас должна быть готовая версия сайта, которую можно взять и использовать на производстве. Бесконечные не работающие прототипы и ковыряние в стадии пре-релиза — это плохо.
С некоторыми заказчиками гибкие методологии вам не помогут. Например с гос заказом вы по закону обязаны работать только по waterfall с четкими этапами и никак иначе. Внутрениие процессы организуйте как вам угодно, но с заказчиком извольте только через waterfall.
Ну и если заказчик крупный и не гибкий, то он будет навязывать свой подход мотивируя это «мы так не работаем», «у нас так не делается», «так нам не согласуют сверху»… Некоторые корпорации еще менее гибкие чем гос структуры.
Ну и если заказчик крупный и не гибкий, то он будет навязывать свой подход мотивируя это «мы так не работаем», «у нас так не делается», «так нам не согласуют сверху»… Некоторые корпорации еще менее гибкие чем гос структуры.
Я, как бы, и не спорю. Гибкие методологии — не панацея. Где-то WF работает. Ничего плохого в этом нет.
Просто у ТС описана ситуация, когда в проекте идут постоянные правки и изменения по инициативе заказчика. И да, в комментариях всплыло, что заказчик оплачивал изменения. А вот ПМ не смог работать в таком режиме.
Просто у ТС описана ситуация, когда в проекте идут постоянные правки и изменения по инициативе заказчика. И да, в комментариях всплыло, что заказчик оплачивал изменения. А вот ПМ не смог работать в таком режиме.
Дел
Вопрос один — вам заплатили за вашу работу?
По моему опыту, в таких проектах надо сначала внимательно выслушать и опросить представителей стороны заказачика, провести с ними несколько встреч. Но потом уже писать ТЗ самому, никого больше не слушая, давить авторитетом, и говорить что ты лучше знаешь как реализовать такой проект. Конечно, по ходу написания ТЗ нужно задавать заказчику появляющиеся вопросы, но ни в коем случае не давать ему влезать в составление проекта. Включайте режим «Мы вас выслушали, мы профессионалы, теперь мы объясняем что и как надо делать.»
В противном случае проект практически гарантированно утонет в обсуждениях, новых «гениальных» идеях, и бесконечном потоке псевдоэкспертов со стороны заказчика.
В противном случае проект практически гарантированно утонет в обсуждениях, новых «гениальных» идеях, и бесконечном потоке псевдоэкспертов со стороны заказчика.
Заказчик бабло отмыл)
Когда ТЗ было утверждено — началось создание прототипов и логической структуры проекта, работа была поистине огромная — сотни страниц прототипов, которые, помимо того, что должны были отображать визуальное структуру — так ещё являлись и своего рода ТЗ для будущего программирования.
О том, что ТЗ было предварительным, мы на тот момент не знали.
суть (с) ТМ
Стандартная история любого государственного проекта в "информатизации здравоохранения". Система была как бы предназначена для врачей и пациентов. Так надо было делать её для врачей и пациентов. Второй исполнитель абсолютно правильно понял, что систему надо делать для заказчика и идеально справился.
потому что заказчик так и не смог понять, что он хочетничего личного, но у вас тоже не хватило ума рассказать заказчику, что каждое изменение требует времени и денег. Каждая его хотелка о которой не договаривались — аналогично. У вас были отличные возможности сделать это на личных встречах — рассказывать такое проще лично, чем в почте. Но переговоры с заказчиком и разговор на языке заказчика — это такая же важная часть проекта как и само программирование.
А в вашем случае оно(переговоры) было даже важнее чем само программирование, потому что вы с заказчиком друг друга не поняли. Можно было даже не напрягать программиста.
И проблема как в статье не зависит — государственный ли заказчик, или нет. Везде есть такие самодуры, которые «всё знают как надо», но к ним тоже нужен подход чтобы всё объяснить на его языке, на крайняк на языке денег.
Я так понимаю, что ТЗ по договору должны были вы сделать. Это нормально, за это часто даже отдельная строка в смете существует. Но в итоге вы его сделали? Пишите, что оно было утверждено, но судя по рассказу им никто не пользовался. Или предполагалось, что оно будет оформлено окончательно, когда будет сделан проект? ТЗ — это гарантия баланса интересов обеих сторон. Если оно утверждено, то за оплату допработ можно уже не беспокоиться. Даже за оплату доработки ТЗ, потому что это отдельная работа. А иначе заказчик лишь воспользуется ситуацией. Причём «не со зла». Он же не профессионал, он не знает как это работает. А вы профессионалы. И позволили ему вообще всё за бесплатно.
Вы абсолютно правы. И это работает, когда заказчик адекватный.
А когда персонаж маскирует паранойю развитым интеллектом, при этом он сам ее не ощущает, и считает свои мысли и действия последовательными, свое мнение — истиной в последней инстанции. Тут ТЗ мало помогает. Сразу в суд.
А когда персонаж маскирует паранойю развитым интеллектом, при этом он сам ее не ощущает, и считает свои мысли и действия последовательными, свое мнение — истиной в последней инстанции. Тут ТЗ мало помогает. Сразу в суд.
Не стоит так уж судов бояться. В России это просто часть бизнес-процессов. Некоторые платят только по суду. Некоторые не понимают либо не идут на компромисс, пока иск не получат. С госзаказчиками в этом плане есть фича. Если идёт где-нибудь третий квартал года уже, то можно неплохо так шантажировать. У них должен быть освоен выделенный им бюджет, то есть все деньги должны быть закрыты выполнением до конца года. Что осталось — должны вернуть обратно в бюджет. За это их накажут, а повторно выклянчивать очень сложно. Поэтому они становятся очень сговорчивыми, когда явно не правы.
Из личного опыта. Сейчас, возможно, правила игры поменялись, но несколько лет назад в ходу была следующая схема. Стройка. Сроки никогда не соблюдаются. Но если напишешь реальные сроки, то тендер не выиграешь, а госзаказчику деньги на долгострой не выделят. В общем, под конец года «обнаруживается», что сдать объект в ближайшем будущем не получится. Подписывается допник с подрядчиком, по которому ему закидывают дополнительный аванс на десятки/сотни миллионов, но с условием, что если он их не отработает в ближайшие три месяца (а он их не отработает физически чисто), то он аванс вернёт обратно. Все счастливы: госзаказчик освоил бюджет, а подрядчик получил халявный многомиллионный кредит на несколько месяцев. Вин-вин.
К чему этот пример… Если госзаказчик неадекват и явно не прав, а близится конец года, то можно рубить концы (разумеется, правильно рубить, и подстраховавшись правильными бумажками), прекращать работы и идти в суд. Чем ближе к концу года, тем больше будет истерики. Но зато компромисс найдётся быстро.
Из личного опыта. Сейчас, возможно, правила игры поменялись, но несколько лет назад в ходу была следующая схема. Стройка. Сроки никогда не соблюдаются. Но если напишешь реальные сроки, то тендер не выиграешь, а госзаказчику деньги на долгострой не выделят. В общем, под конец года «обнаруживается», что сдать объект в ближайшем будущем не получится. Подписывается допник с подрядчиком, по которому ему закидывают дополнительный аванс на десятки/сотни миллионов, но с условием, что если он их не отработает в ближайшие три месяца (а он их не отработает физически чисто), то он аванс вернёт обратно. Все счастливы: госзаказчик освоил бюджет, а подрядчик получил халявный многомиллионный кредит на несколько месяцев. Вин-вин.
К чему этот пример… Если госзаказчик неадекват и явно не прав, а близится конец года, то можно рубить концы (разумеется, правильно рубить, и подстраховавшись правильными бумажками), прекращать работы и идти в суд. Чем ближе к концу года, тем больше будет истерики. Но зато компромисс найдётся быстро.
нет, тз утвердили, начали делать, в ходе работ возникали уже доработки, за которые заказчик естественно платил
Специфика работы с врачами в чистом виде тут( Мне пришлось разрабатывать для врачей несколько программ (заказчик — частная компания). Как правило, лишь отдельные специалисты (часто кстати кардиологи) ставят адекватные задачи и способны понять, когда им говоришь, что так делать нельзя. Остальным надо говорить «это технически невозможно» — так вы сбережете себе нервы и время. В итоге пришел к тому, что проводил несколько встреч с обсуждением деталей ТЗ, которое затем писал сам, а заказчик знакомился и подписывал. После этого вмешиваться в разработку он не мог.
Это имхо из личного опыта
Это имхо из личного опыта
Знаю таких двоих. Один из Москвы, другой из Питера. Проекты идентичные, не сговариваясь, оба мне кровушки попили и нервушки изрядно потрепали, 2014-2016.
Интересно, вам попался один из этих двух, или третий?..
Интересно, вам попался один из этих двух, или третий?..
Гос не гос, равно как и страна, мне кажется, роли не играет. Определенный тип заказчиков.
У меня в начале 2015 года была ситуация. Германия, маленькая семейная фирма, очень интересный на первый взгляд проект — нужет вебшоп в очень специфической тематике.
Я на тот момент между работами, хозяин хочет все только чтобы я был штатной единицей его фирмы, 40 часов в неделю. Так как «ты должен быть всегда рядом, потому что у меня столько идей всегда, что я должен их незамедлительно озвучивать».
Все это вылилось в то, что после нескольких прототипов и его многочисленных и постоянно меняющихся хотелок я уже не мог этого всего выносить, и предложил ему промежуточный вариант, что то вроде лендинга, пока все его пожелания не сформируются в четкий задокументированный проект…
В результате, спустя почти 4 года, у него, кроме того самого лендинга, что я сваял за пару недель и что должен был просуществовать не дольше года, ничего так и нет. Как уже почти 3 года нет и меня у него на фирме…
А идею до сих пор считаю очень даже неплохой.
У меня в начале 2015 года была ситуация. Германия, маленькая семейная фирма, очень интересный на первый взгляд проект — нужет вебшоп в очень специфической тематике.
Я на тот момент между работами, хозяин хочет все только чтобы я был штатной единицей его фирмы, 40 часов в неделю. Так как «ты должен быть всегда рядом, потому что у меня столько идей всегда, что я должен их незамедлительно озвучивать».
Все это вылилось в то, что после нескольких прототипов и его многочисленных и постоянно меняющихся хотелок я уже не мог этого всего выносить, и предложил ему промежуточный вариант, что то вроде лендинга, пока все его пожелания не сформируются в четкий задокументированный проект…
В результате, спустя почти 4 года, у него, кроме того самого лендинга, что я сваял за пару недель и что должен был просуществовать не дольше года, ничего так и нет. Как уже почти 3 года нет и меня у него на фирме…
А идею до сих пор считаю очень даже неплохой.
Хороший урок, для вас.
Роснацздравнадзор…
сколько же их расплодилось этих Абырвалгов…
сколько же их расплодилось этих Абырвалгов…
Исходя из описанного, думаю, вы были неготовы к изменениям. Ну сделали бы вы вашу систему и она в тот же день умерла, потому что вы не можете её развивать. Это с точки зрения архитектуры. С точки зрения управления проектом и контрактных отношений, видимо, не там была проведена граница ответственности. Вмешиваться в детали заказчик, может быть, и может, но вы должны быть готовы оба.
Это независимо от того как отжигал заказчик
Это независимо от того как отжигал заказчик
Заказчику просто нравится ковыряться в проекте собственными руками. Так он себя ощущает творцом, не будучи таковым. Ведь чем больше он него лезет, включая технические моменты реализации, тем больше у него появляется ощущение, что проект он выносил буквально на руках (о чем и будет рассказывать друзьям в бане). Для этого подобным заказчикам нужен определенный тип исполнителя
Судя по всему, это должен был получиться клон diagnose.me, дизайн очень даже неплох был в прототипах, но вот идея… Ах да, еще прием к врачу планировалось реализовать, кроме консультаций, но и такое уже есть — агрегаторы всяческие с записью.
Если заказчик вам за все заплатил — он вообще лапочка. И имеет право все наработки выкинуть. Если бы прокидал — другая история!
А вот то, что он явно вынужден был пойти на отчаянные меры, и в результате ему оказалось проще рулить програмером самому, а потом и вовсе пилить Тильду — значит, где-то вы в общении сильно накосячили, перестали его слушать или не смогли прийти к согласию.
По дизайну — извините, это не дизайн. Это довольно детально проработанный прототип, или начальная стадия, но готового дизайна там не видно. Плюс несколько серьезных косяков: вы делаете сайт, достаточно большой частью аудитории которого будут люди с не лучшим зрением, но набираете большое количество текстов мелким шрифтом. Или, например, что будет с дизайном личного кабинета, если понадобится достаточно вероятное действие — добавление оплаты через Яндекс.Деньги?
Ну и в целом, засветить вот так заказчика — очень другой тон.
Если он выполнил перед вами все финансовые обязательства, а других не было, и решил переделать проект у других дизайнеров — чтобы продать идею инвесторам или отчитаться перед министерством, например — да мало ли! — то вы им можете таким образом довольно сильно подгадить.
это жалобная книга?
А вот то, что он явно вынужден был пойти на отчаянные меры, и в результате ему оказалось проще рулить програмером самому, а потом и вовсе пилить Тильду — значит, где-то вы в общении сильно накосячили, перестали его слушать или не смогли прийти к согласию.
Проще рулить? А может дешевле платить напрямую программисту, чем агентству? Вы об этом подумали? В обход нас заказчик написал программисту не ради общения, а ради экономии. Это во первых. Во вторых, общение у нас было более чем адекватное, за всю работу было порядка 20 встреч в разных местах где мы обсуждали не только проект, но и вели многие другие разговоры. Если вы сомневаетесь в нашей компетентности(к слову говоря да, местами были некомпетентны), то что вы скажите на то, что в ходе работы сменились 2 эксперта в медицинской сфере? Они тоже были некомпетентны?
По дизайну. Странно что его не оценили только вы, ведь другие комментаторы говорили об обратном.
Добавление яндекс.денег причем тут вообще? Оплата внедрена была в момент заключения и подтверждения консультации.
Проект от частного лица а не государственного заказчика, просто размах на проект федерального уровня. Мы поделились лишь кейсом о нашем проекте, где реальный опыт. У нас нету цели очернить кого-нибудь или подгадить.
Проще рулить? А может дешевле платить напрямую программисту, чем агентству? Вы об этом подумали? В обход нас заказчик написал программисту не ради общения, а ради экономии.
А что значит «в обход вас»? Вы были третьей стороной, программиста привлекали в проект не вы? В моём понимании программист должен был послать заказчика, кхм, обратно к вам. Это fair play любого сотрудничества.
Простите, если вы. агентство, то откуда у клиента вообще контакты программиста? Тем более, если это не ваш программист? На то и менеджеры, чтобы с клиентом общались только те, кому можно, и те, кто это умеет.
Про "экспертов в медицинской сфере" я вообще не очень понял, при чем они тут. Вы сайт для экспертов-медиков делали? Если нет, то вам скорее нужна помощь не кардиолога или стоматолога, а главврача. Зачем их меняли — из вашего описания неясно.
По дизайну вообще не хотел придираться, т.к. вы об этом не просили. Поэтому написал только в общем, с точки зрения заказчика — на готовый дизайн это не очень тянет, я бы такую работу не принял.
Про "подгадить" — получается, что вы засветили и имя, и идею заказчика до полной реализации. Странно, что у вас никакого NDA не подписано, видимо, заказчик не очень опытный. Но, даже если он не запретил это прямо через NDA, хороший тон — заменить логотипы, а лучше — ещё и заменить врачей на, например, сантехников или репетиторов. Статья от этого ничего не потеряла бы.
У меня ощущение, что заказчик вас просто подавил своей властью, которая при этом сочеталась с расхлябанностью с обеих сторон. Гибкость гибкостью, а новых требований по ходу проекта должно становиться меньше, а работающего продакшен кода — больше. Если не становится — нужно проявлять волю и указывать на проектировочные документы, брать и отказывать в новых фичах.
«Совещания становились брейнстормом» — ну дык, а кто делал план совещания? Кто стукал линейкой по рукам всех, кто идет не по плану совещания?
Аналогично с вашими идеями — ну что это значит, «категорический отказ». Отказ бывает мотивированным чем-то.
Ну и оплата программисту в обход компании — это просто цирк, всецело лежащий на совести руководителя проекта. Руководитель не только не наладил коммуникации, у него в команде просто отсутствует субординация.
В чем вы большие молодцы — это в том, что правильно организовали схему оплаты и получили свои денежки. Иначе было бы совсем обидно.
«Совещания становились брейнстормом» — ну дык, а кто делал план совещания? Кто стукал линейкой по рукам всех, кто идет не по плану совещания?
Аналогично с вашими идеями — ну что это значит, «категорический отказ». Отказ бывает мотивированным чем-то.
Ну и оплата программисту в обход компании — это просто цирк, всецело лежащий на совести руководителя проекта. Руководитель не только не наладил коммуникации, у него в команде просто отсутствует субординация.
В чем вы большие молодцы — это в том, что правильно организовали схему оплаты и получили свои денежки. Иначе было бы совсем обидно.
Как же это знакомо.
Помнится портал делал, очень крупный, с превосходной заявкой на будущее. Он начал зарабатывать еще до того, как был готов сайт. Многие были в нем заинтересованы. Но вот вместо запуска малой версии, руководство решило менять все и вся. Дошло до того, что во вт. я получал задание, просто забивал на него, а в чт. это задание отменялось и перерабатывалось в другое. И не потому, что я забивал. Оно бы изменилось в любом случае, и я решил не тратить время на бесполезный код. И так практически каждую неделю.
Посчитал свои затраты, сказал «ребята я все», передал полностью управление другому разрабу, получил гонорар, где полезный выхлоп составил чуть более 7к (остальное это приезды, обеды и прочее), и удалился восвояси. Потом тоже сделал второй разраб. Третий…
Проект умер.
Помнится портал делал, очень крупный, с превосходной заявкой на будущее. Он начал зарабатывать еще до того, как был готов сайт. Многие были в нем заинтересованы. Но вот вместо запуска малой версии, руководство решило менять все и вся. Дошло до того, что во вт. я получал задание, просто забивал на него, а в чт. это задание отменялось и перерабатывалось в другое. И не потому, что я забивал. Оно бы изменилось в любом случае, и я решил не тратить время на бесполезный код. И так практически каждую неделю.
Посчитал свои затраты, сказал «ребята я все», передал полностью управление другому разрабу, получил гонорар, где полезный выхлоп составил чуть более 7к (остальное это приезды, обеды и прочее), и удалился восвояси. Потом тоже сделал второй разраб. Третий…
Проект умер.
Почему я дергаюсь, видя префиксы «рос» и «нац»? Ладно, что американская калька (все эти «национальные» штуки), так еще и в голове подсознательная четкая уверенность, что это нифига не официально серьезное дело, а очередное очковтирательство.
Рад бы ошибиться и увидеть обратный пример!
Про «заказчика» как-то вскользь все время, но все же интересно, за чей счет работы-то велись — это мы же с вами из налогов оплатили, или это коммерческое начинание?
Рад бы ошибиться и увидеть обратный пример!
Про «заказчика» как-то вскользь все время, но все же интересно, за чей счет работы-то велись — это мы же с вами из налогов оплатили, или это коммерческое начинание?
По моему мнению, исходно в статье очень корректно и мягко (и, возможно, с обидой от того, что не оправдались несколько наивные ожидания) описан подход российских окологос- и гос-заказчиков, тем более в сфере здравоохранения, к реализации ИТ-проектов.
(Сразу примечание-оговорка — нужно делить гос- и окологос-. Для представителей гос-заказчиков существуют хоть какие-то формы контроля и вероятность ответственности за «суммарно понесенный эффект» — выговор в личном деле пожизненно не приятен, также можно и под горячую руку попасть (никто же не знает, какая жалоба и по какому вопросу «выиграет лотерею», например, на прямой линии). Для окологос- о какой-либо ответственности речь не идет, потому что комплексные договоренности о «вертикали» распределения бюджета размывают понятие ответственности, распределение бюджета уже согласовано задолго до того, как менеджеры Исполнителя провели 1-ую встречу с представителями окологос-.
Попробую систематизировать некоторые взаимодополняющие проблемы реализации ИТ-проектов в таких заказчиках:
1) Бесконечный цикл уточнения и «переосмысления» требований — с многократными (через квартал-полгода) возвратами к аспектам, которые раньше эти же люди категорически отвергли;
2) Пункт 1 дополняется категорическим нежеланием (или неспособностью?) не то что читать, а хотя бы просматривать документацию — то что бюрократически называется «согласовать в рабочем порядке» принципиально не работает, а кроме этого, принципиально не работают и попытки согласовать (и попросить документ, решение о согласовании, протокол....) документацию в официальном порядке — направлением официальных писем, получением номеров входящих, напоминаниями назначенным исполнителям, что нужно бы рассмотреть документацию и т.п.;
Насчет нежелания работать с документацией — много ярких примеров с просьбами сделать выжимки из выжимок из выжимок — … «все равно больше двух абзацев читать не будем...»
3) Подчеркнуто-наигранно-выставляемое-на-показ отсутствие элементарных представлений об информационных технологиях. Например, когда после полугодовых итераций наконец-то хоть как-то договорились об основных сущностях и процессах, демонстрируемый прототип интерфейса (сделанный чтобы хоть как-то зафиксировать договоренности) вызывает неадекватный восторг — «о! все работает! отлично ребята — долго запрягали, но наконец-то сделали...» и попытки сказать что еще конь не валялся в части детализации схемы данных, бизнес-логики, оценок нагрузки, и прочих аспектах, наталкиваются на аргумент — «ну да ладно, за пару недель сделаете? а мы вам уже не нужны...»;
4) Еще один очень важный момент — в таких заказчиках цикл принятия решений в большинстве случаев оказывается длиннее цикла смены лиц, принимающих решения
— что дополнительно усугубляет п. 1.
Ну и так далее — об этом можно написать отдельную статью.
Справедливости ради необходимо отметить, что:
1) все реальные проекты в области здравоохранения и социальной сферы отличаются высокой сложностью (сущность «пациент» гораздо сложнее сущности «гражданин», высокая противоречивая зарегулированность и т.п.)
2) подобные проблемы есть не только у нас — пример с провалом ИТ-проекта Обамы известен всем; еще подобрана информация здесь www.cnews.ru/articles/2018-04-25_velikobritaniyasshaavstraliya_samye_epichnye_provaly_zarubezhnyh
(Сразу примечание-оговорка — нужно делить гос- и окологос-. Для представителей гос-заказчиков существуют хоть какие-то формы контроля и вероятность ответственности за «суммарно понесенный эффект» — выговор в личном деле пожизненно не приятен, также можно и под горячую руку попасть (никто же не знает, какая жалоба и по какому вопросу «выиграет лотерею», например, на прямой линии). Для окологос- о какой-либо ответственности речь не идет, потому что комплексные договоренности о «вертикали» распределения бюджета размывают понятие ответственности, распределение бюджета уже согласовано задолго до того, как менеджеры Исполнителя провели 1-ую встречу с представителями окологос-.
Попробую систематизировать некоторые взаимодополняющие проблемы реализации ИТ-проектов в таких заказчиках:
1) Бесконечный цикл уточнения и «переосмысления» требований — с многократными (через квартал-полгода) возвратами к аспектам, которые раньше эти же люди категорически отвергли;
2) Пункт 1 дополняется категорическим нежеланием (или неспособностью?) не то что читать, а хотя бы просматривать документацию — то что бюрократически называется «согласовать в рабочем порядке» принципиально не работает, а кроме этого, принципиально не работают и попытки согласовать (и попросить документ, решение о согласовании, протокол....) документацию в официальном порядке — направлением официальных писем, получением номеров входящих, напоминаниями назначенным исполнителям, что нужно бы рассмотреть документацию и т.п.;
Насчет нежелания работать с документацией — много ярких примеров с просьбами сделать выжимки из выжимок из выжимок — … «все равно больше двух абзацев читать не будем...»
3) Подчеркнуто-наигранно-выставляемое-на-показ отсутствие элементарных представлений об информационных технологиях. Например, когда после полугодовых итераций наконец-то хоть как-то договорились об основных сущностях и процессах, демонстрируемый прототип интерфейса (сделанный чтобы хоть как-то зафиксировать договоренности) вызывает неадекватный восторг — «о! все работает! отлично ребята — долго запрягали, но наконец-то сделали...» и попытки сказать что еще конь не валялся в части детализации схемы данных, бизнес-логики, оценок нагрузки, и прочих аспектах, наталкиваются на аргумент — «ну да ладно, за пару недель сделаете? а мы вам уже не нужны...»;
4) Еще один очень важный момент — в таких заказчиках цикл принятия решений в большинстве случаев оказывается длиннее цикла смены лиц, принимающих решения
— что дополнительно усугубляет п. 1.
Ну и так далее — об этом можно написать отдельную статью.
Справедливости ради необходимо отметить, что:
1) все реальные проекты в области здравоохранения и социальной сферы отличаются высокой сложностью (сущность «пациент» гораздо сложнее сущности «гражданин», высокая противоречивая зарегулированность и т.п.)
2) подобные проблемы есть не только у нас — пример с провалом ИТ-проекта Обамы известен всем; еще подобрана информация здесь www.cnews.ru/articles/2018-04-25_velikobritaniyasshaavstraliya_samye_epichnye_provaly_zarubezhnyh
Sign up to leave a comment.
Как превратить федеральный проект в сайт-визитку? Почти подробная инструкция