Только представьте, федеральная ассоциация, которая объединит в себе медицинские организации со всей России, позволит простым пациентам из любой точки страны, получить онлайн-консультацию профильного специалиста, скажем, из Москвы, а при необходимости записываться и на реальный прием.
На начальной стадии могло немного насторожить, что описанная выше концепция и была сутью ТЗ. Но проект интересный и амбициозный — поэтому принять участие в формировании более адекватного ТЗ было даже интересно.
В итоге оно было сформировано. Предполагалось создать максимально понятную оболочку продукта в виде сайта, где клиент, предоставив минимальный набор параметров, попадал в личный кабинет, который и был основной проекта.
Помимо этого для привлечения организации в ассоциацию предлагалось участие последних в законотворческой инициативе. Проще говоря, если собрать несколько крупных организаций в одну ассоциацию, вполне можно лоббировать законы, которые помогут осуществлять их деятельность.
Заказчик, правда, очень боялся использовать слово “лоббировать”, хотя в нём нет ничего негативного, и даже попросил исключить его из презентации проекта, но об этом позже.
Личный кабинет, точнее личные кабинеты, представляли собой многоуровневую систему взаимодействий между врачом, пациентом, организацией, а также между врачами разных организаций.
Когда ТЗ было утверждено — началось создание прототипов и логической структуры проекта, работа была поистине огромная — сотни страниц прототипов, которые, помимо того, что должны были отображать визуальное структуру — так ещё являлись и своего рода ТЗ для будущего программирования.
О том, что ТЗ было предварительным, мы на тот момент не знали. К счастью (ну, как выяснилось позже, к несчастью) заказчик предпочитал личные встречи для обсуждения проекта. Обычно — это даже лучше, позволяет ускорить процесс, и согласовать отдельные детали в режиме “plug&play”.
Но, увы, каждая встреча становилась не рубежом, после которого должен был начаться следующий этап разработки, а мозговым штурмом, в духе: “А давайте вот так сделаем!”, “А вот мне тут идею подкинули”. В итоге уже готовые прототипы приходилось переделывать, причем, учитывая достаточно прямую взаимосвязь всех элементов кабинета — небольшая, по виду, правка, могла привести к тому, что изменять приходилось практически всё. Наверное, и не стоит говорить — что заказчик считал правки такого рода обычным рабочим процессом, и увеличивать смету целесообразным не считал.
Практически на каждой встречи выяснились новые обстоятельства, вроде невозможности определенных видов консультаций, например консультации “врач-пациент” по законам Российской Федерации, и необходимости для пациента идти к врачу в своём городе, и в его присутствии проводить онлайн-консультацию. Причём последний должен был быть членом ассоциации для непосредственной возможности использования личного кабинета и самого ПО для проведения сеанса TrueConf, интегрированную в личный кабинет.
Отдельно стоит упомянуть про экспертность, и ее значимость при разработке проектов. Первое время, на встречах присутствовал достаточно известный врач-кардиолог, он, что называется, ратовал за продукт, а не за его оболочку. Предлагал действительно интересные идеи, и что важнее — считал более важным реальный запуск проекта, чем его бесконечную переделку «на коленке». Учитывая, что он настоящий врач, казалось бы, к его советам надо прислушаться. Но, судя по тому, что после 3-ей встречи он из проекта выбыл — экспертность посчитали не самым важным параметром при разработке. Что забавно — вместо кардиолога, на одну из следующих встреч, пришёл уже стоматолог.
В итоге было подготовлено две итерации дизайна, согласование которых, к счастью, прошло без особых проблем.
А дальше начался самый настоящий треш и угар, заказчик, видимо не понимая как именно происходит процесс программирования, решил связаться с программистом сам, в обход нас, и не просто связаться, но и начать давать ему новые вводные напрямую, а позже решил и вовсе платить ему напрямую, но при этом, продолжая работать с нами.
В итоге, сверстанный и выкаченный проект оказался в стазисе, потому что программная часть была построена на новых неожиданных идеях, которые никто до нас не донес. Программист, видимо, посчитал, что это сделал заказчик — а заказчик посчитал, что всё автоматически интегрируется и будет работать, какие правки не давай.
Несмотря на то, что мы продолжали сотрудничество, подготовили полноценную презентацию проекта, макеты визиток сотрудников и компаньонов заказчика (которые, по ходу работы, менялись два раза) — огромный проект так и не смог взлететь.
Ещё на начальном этапе мы предлагали добавить проект на ФРИИ (Фонд Развития Интернет-Инициатив), проработать слабые места, узнать дополнительные экспертные мнения — но заказчик эту идею отверг. Он и так знает, что делать. Примечательно это тем, что несколько месяцев спустя, в общем чате мы увидели сообщение в духе: «А почему мы ФРИИ не использовали?»
В итоге, в каком-то отчаянном шаге, заказчик нашел дизайнера, который сделал абсолютно странный, и не соответствующий логике дизайн, а после, так и вовсе нанял компанию (мы так и не выяснили какую), которая превратила огромный федеральный проект в небольшой сайт-визитку на тильде, в котором даже не потрудились подобрать качественные изображения, а кнопка «Личный кабинет» в углу экрана так и осталась кнопкой ведущий в никуда.
Всегда печально, когда интересный проект не доходит до реализации, но еще печальнее, когда уже почти реализованный проект умирает, потому что заказчик так и не смог понять, что он хочет, а новых замечательных идей, с каждым разом было всё больше.
Как итог, сайт-визитка вместо федерального многофункционального портала.
Комментарии (60)
poloart
04.11.2018 21:19+3Я бы вообще не стал работать с государственными организациями.
Для меня это как табу.
Странно, что некоторые себе позволяют видеть «Роснац...» в виде «заказчика».
Шли бы они в пень, себе потом будет дороже с такими работать.
Слишком много вокруг примеров, господа.roboqueer
04.11.2018 22:33+1Это не государственный заказчик. Это какая-то мутная «ассоциация» с названием, похожим на что-то «государственное».
poloart
04.11.2018 22:39+1Да тем более.
Мы столько секса поимели с «интерсекьюритифорум», что никому такого не пожелаю.
Оно даже гуглится — можете посмотреть.
Всё, что косит под государственную структуру, всё, что в составе заказчиков имеет государственные структуры — ровным строем идёт в пень.
Иначе, у вас будет секс на каждом этапе согласования, создания и внедрения.
Проще частникам сделать интернет-магазин керамической плитки.
DrPass
05.11.2018 04:17Да и среди негосударственных таких миллион. Но как по мне, тут и разработчик наделал ошибок со своей стороны. Заказчику-то несложно сказать «а давайте всё переделаем нафиг». Но разработчик в ответ на это не должен всё переделывать нафиг (ещё и без увеличения сметы), а объяснить заказчику, сколько и почему это ему будет стоить, и по деньгам, и по срокам.
А ещё, пункт о разрешении таких ситуаций (а-ля «в случае изменений уже разработанного функционала такие работы выполняются как дополнительные, за отдельную плату»). необходимо изначально включать в договор с заказчиком. Благо, он обычно даже с самыми сложными заказчиками не вызывает вопросов.
AquiHostStrider
05.11.2018 09:18+5«Если вы не любите людей — значить вы просто не умеете их готовить»(с)Людоед.
Нет, государственный заказчик — это особенный заказчик типа «араб», к которому нужен особенный подход. Особенность в том, что с ним ни в коем случае не надо пытаться «дружить», надеясь на дальнейшее сотрудничество и партнёрство (ибо сами знаете насчёт страны...), а стараться брать оплату за каждый взбрык. Переделка макета — столько-то, реализация идеи — столько-то, реализация глупой идеи — в двойном размере, ложный вызов менеджера по работе с клиентами — гоните оплату, барин. Итоговый проект не взлетит с вероятностью 90%, это нужно просто принять как данность. Но главное — самим в пролёте не остаться по деньгам.
valis
05.11.2018 15:05+1Тут нужно понимать специфику.
У этих людей нет ни капли заинтересованности в выпуске продукта. Большие дяди собрались и решили запилить проект, выбили бюджет и спустили задачу более мелким дядям (задачу спустили а цели, что важно, так и остались в голове у больших дядь, если вообще не были забыты).
А далее стандартный сценарий — есть бюджет, есть задачи и есть люди, которым сказано копать от забора до обеда они и капают от забора до обеда. Их главная цель (если не разводить холивары про откаты) — соблюдать спущенные с верху сроки и деньги + получать ЗП. Интереса в запуске продукта уже нет.
Тоесть если Вы хотите заработать относительно легкие деньги и у вас команда чуть ниже среднего (там явно не нужны супер звездная команда разработки, дизайнеры от бога или не спящие ночами продакт овнеры) велкам на тендеры к гос сектору или внутренние проекты крупных корпораций (там примерно творится тоже самое что и в гос структурах)
Imbecile
04.11.2018 21:251. От постоянных правок помогают гибкие методологии. А вы, похоже, решили всё и сразу задизайнить, а потом реализовать.
2. Не совсем понятна ваша роль. За что отвечали в проекте?
mekhaga Автор
04.11.2018 21:29Можно узнать подробнее про гибкую методологию? Мы сначала сделали кучу прототипов, а потом дизайн.
Я и проджект и дизайнер проектаImbecile
04.11.2018 21:51+1https://ru.wikipedia.org/wiki/Гибкая_методология_разработки
Исходя из вопроса, я начинаю догадываться о причинах описанного развития проекта.roboqueer
04.11.2018 22:38+1Собственно, статья не просто про провал проекта, а про некомпетентность всех сторон — и прежде всего, автора статьи.
mekhaga Автор
04.11.2018 22:41Очень интересно на чем основан ваш аргумент? В каком месте мы были некомпетентны? Все было в срок, соответствовало все ТЗ, все этапы были согласованы. А оценивать уровень компетентности по постоянным доработкам заказчика, это как-то… глупо
Imbecile
04.11.2018 22:49+2Есть такое понятие: управление ожиданиями заказчика. И вот тут вы похоже не справились, как ПМ. Потому как работа ПМ, в том числе, заключается в том, чтобы предложить такой подход, который бы учитывал постоянные правки. Я не зря упомянул гибкие методологии. Они действительно могут помочь. И когда человек, который называет себя ПМ, с одной стороны, спрашивает: что это такое, agile? А с другой стороны, сваливает неудачу проекта на заказчика, который постоянно приносит правки, возникают резонные сомнения в его компетентности.
mekhaga Автор
04.11.2018 22:52Ну в статье написано, что на все наши идеи были категоричные отказы. Какое бы вы решение могли предложить?
TimsTims
05.11.2018 10:14+3Самый правильный вариант в таком случае — каждое изменение или отступление от ТЗ — это деньги+время. Если заказчик и на такие ваши «идеи» отвечает категоричным отказом, то сразу очевидно, что ничего не получится.
Delphinum
05.11.2018 13:13Гибкие методики это не серебренная пуля, они никак не помогут при работе с заказчиков вида — а давайте все переделаем. Вы неделю пилите пачку мелких функциональностей, а на следующем совещании вам говорят — вы ничего из того, о чем мы договаривались не сделали, мы обратимся в другую компанию, а с вами посоветуем никому дел не иметь.
В данном случае только метод «каждая работа должна оплачиваться» без попыток «подружиться» с клиентом.Imbecile
05.11.2018 13:581.
Гибкие методики это не серебренная пуля
Да, согласен, agile — не серебряная пуля. Но, он может сильно помочь в описанной ситуации, если уметь им пользоваться.
2.они никак не помогут при работе с заказчиков вида — а давайте все переделаем.
Они как раз на такое и рассчитаны. Закончили спринт (допустим, здесь и далее у нас Scrum). А дальше — хоть с нуля, хоть переноси с веб на десктоп. Главное, спланировать на следующий спринт.
3.Вы неделю пилите пачку мелких функциональностей, а на следующем совещании вам говорят — вы ничего из того, о чем мы договаривались не сделали, мы обратимся в другую компанию, а с вами посоветуем никому дел не иметь.
«Гибкая методология» — не равно «отсутствие требований, плана и т.п.». Нельзя работу работать в спринте и в итоге сделать не то, что было поставлено, как цели на спринт, а что-то другое. И договорённости все фиксируются. И закзачик сам принимает участие в определении целей.
4.В данном случае только метод «каждая работа должна оплачиваться» без попыток «подружиться» с клиентом.
Одно другому не мешает. Работа должна быть оплачена всегда.
tommyangelo27
04.11.2018 23:03На доработки заказчика можно соглашаться только с подписанным Change Order. Все остальное (включая чаты, емейлы, личные разговоры) — это не документы, к делу не подошьешь. Соглашаться на доработки бесплатно и не задокументированно — путь к закономерному провалу.
mekhaga Автор
04.11.2018 23:06Да нет же, все это было за доплату, естественно. Каждая доработка оплачивалась и подписывались промежуточные акты.
ganqqwerty
05.11.2018 16:23+1Вот это неправильно. В любой момент времени у вас должна быть готовая версия сайта, которую можно взять и использовать на производстве. Бесконечные не работающие прототипы и ковыряние в стадии пре-релиза — это плохо.
tushev
05.11.2018 01:23+1С некоторыми заказчиками гибкие методологии вам не помогут. Например с гос заказом вы по закону обязаны работать только по waterfall с четкими этапами и никак иначе. Внутрениие процессы организуйте как вам угодно, но с заказчиком извольте только через waterfall.
Ну и если заказчик крупный и не гибкий, то он будет навязывать свой подход мотивируя это «мы так не работаем», «у нас так не делается», «так нам не согласуют сверху»… Некоторые корпорации еще менее гибкие чем гос структуры.Imbecile
05.11.2018 14:10Я, как бы, и не спорю. Гибкие методологии — не панацея. Где-то WF работает. Ничего плохого в этом нет.
Просто у ТС описана ситуация, когда в проекте идут постоянные правки и изменения по инициативе заказчика. И да, в комментариях всплыло, что заказчик оплачивал изменения. А вот ПМ не смог работать в таком режиме.
Sovetnikov
05.11.2018 00:42+2Вопрос один — вам заплатили за вашу работу?
mekhaga Автор
05.11.2018 01:02+1Да
YemSalat
06.11.2018 11:11А выкладывание дизайнов в паблик — это ОК с юридической точки зрения после завершения проекта? Правда интересно.
mekhaga Автор
06.11.2018 11:14Ну это не исходники, это просто картинки, превью макетов + никаких NDA и никакой передачи исключительных авторских прав не было. Поэтому — это ОК.
tushev
05.11.2018 01:00+1По моему опыту, в таких проектах надо сначала внимательно выслушать и опросить представителей стороны заказачика, провести с ними несколько встреч. Но потом уже писать ТЗ самому, никого больше не слушая, давить авторитетом, и говорить что ты лучше знаешь как реализовать такой проект. Конечно, по ходу написания ТЗ нужно задавать заказчику появляющиеся вопросы, но ни в коем случае не давать ему влезать в составление проекта. Включайте режим «Мы вас выслушали, мы профессионалы, теперь мы объясняем что и как надо делать.»
В противном случае проект практически гарантированно утонет в обсуждениях, новых «гениальных» идеях, и бесконечном потоке псевдоэкспертов со стороны заказчика.Delphinum
05.11.2018 13:36+1Это создает другой риск — после сдачи проекта вам говорят «проект не отвечает нашим потребностям», а на все ваши возражения вы услышите «ну мы же вам говорили, а вы не слушал»
Mimus_spb
05.11.2018 05:11Когда ТЗ было утверждено — началось создание прототипов и логической структуры проекта, работа была поистине огромная — сотни страниц прототипов, которые, помимо того, что должны были отображать визуальное структуру — так ещё являлись и своего рода ТЗ для будущего программирования.
О том, что ТЗ было предварительным, мы на тот момент не знали.
суть (с) ТМ
Wandy
05.11.2018 06:12Стандартная история любого государственного проекта в "информатизации здравоохранения". Система была как бы предназначена для врачей и пациентов. Так надо было делать её для врачей и пациентов. Второй исполнитель абсолютно правильно понял, что систему надо делать для заказчика и идеально справился.
TimsTims
05.11.2018 10:09потому что заказчик так и не смог понять, что он хочет
ничего личного, но у вас тоже не хватило ума рассказать заказчику, что каждое изменение требует времени и денег. Каждая его хотелка о которой не договаривались — аналогично. У вас были отличные возможности сделать это на личных встречах — рассказывать такое проще лично, чем в почте. Но переговоры с заказчиком и разговор на языке заказчика — это такая же важная часть проекта как и само программирование.
А в вашем случае оно(переговоры) было даже важнее чем само программирование, потому что вы с заказчиком друг друга не поняли. Можно было даже не напрягать программиста.
И проблема как в статье не зависит — государственный ли заказчик, или нет. Везде есть такие самодуры, которые «всё знают как надо», но к ним тоже нужен подход чтобы всё объяснить на его языке, на крайняк на языке денег.
SelectVim
05.11.2018 10:29+1Я так понимаю, что ТЗ по договору должны были вы сделать. Это нормально, за это часто даже отдельная строка в смете существует. Но в итоге вы его сделали? Пишите, что оно было утверждено, но судя по рассказу им никто не пользовался. Или предполагалось, что оно будет оформлено окончательно, когда будет сделан проект? ТЗ — это гарантия баланса интересов обеих сторон. Если оно утверждено, то за оплату допработ можно уже не беспокоиться. Даже за оплату доработки ТЗ, потому что это отдельная работа. А иначе заказчик лишь воспользуется ситуацией. Причём «не со зла». Он же не профессионал, он не знает как это работает. А вы профессионалы. И позволили ему вообще всё за бесплатно.
customtema
05.11.2018 10:36Вы абсолютно правы. И это работает, когда заказчик адекватный.
А когда персонаж маскирует паранойю развитым интеллектом, при этом он сам ее не ощущает, и считает свои мысли и действия последовательными, свое мнение — истиной в последней инстанции. Тут ТЗ мало помогает. Сразу в суд.SelectVim
05.11.2018 17:38Не стоит так уж судов бояться. В России это просто часть бизнес-процессов. Некоторые платят только по суду. Некоторые не понимают либо не идут на компромисс, пока иск не получат. С госзаказчиками в этом плане есть фича. Если идёт где-нибудь третий квартал года уже, то можно неплохо так шантажировать. У них должен быть освоен выделенный им бюджет, то есть все деньги должны быть закрыты выполнением до конца года. Что осталось — должны вернуть обратно в бюджет. За это их накажут, а повторно выклянчивать очень сложно. Поэтому они становятся очень сговорчивыми, когда явно не правы.
Из личного опыта. Сейчас, возможно, правила игры поменялись, но несколько лет назад в ходу была следующая схема. Стройка. Сроки никогда не соблюдаются. Но если напишешь реальные сроки, то тендер не выиграешь, а госзаказчику деньги на долгострой не выделят. В общем, под конец года «обнаруживается», что сдать объект в ближайшем будущем не получится. Подписывается допник с подрядчиком, по которому ему закидывают дополнительный аванс на десятки/сотни миллионов, но с условием, что если он их не отработает в ближайшие три месяца (а он их не отработает физически чисто), то он аванс вернёт обратно. Все счастливы: госзаказчик освоил бюджет, а подрядчик получил халявный многомиллионный кредит на несколько месяцев. Вин-вин.
К чему этот пример… Если госзаказчик неадекват и явно не прав, а близится конец года, то можно рубить концы (разумеется, правильно рубить, и подстраховавшись правильными бумажками), прекращать работы и идти в суд. Чем ближе к концу года, тем больше будет истерики. Но зато компромисс найдётся быстро.
mekhaga Автор
05.11.2018 13:18нет, тз утвердили, начали делать, в ходе работ возникали уже доработки, за которые заказчик естественно платил
krylov_sn
06.11.2018 06:53Специфика работы с врачами в чистом виде тут( Мне пришлось разрабатывать для врачей несколько программ (заказчик — частная компания). Как правило, лишь отдельные специалисты (часто кстати кардиологи) ставят адекватные задачи и способны понять, когда им говоришь, что так делать нельзя. Остальным надо говорить «это технически невозможно» — так вы сбережете себе нервы и время. В итоге пришел к тому, что проводил несколько встреч с обсуждением деталей ТЗ, которое затем писал сам, а заказчик знакомился и подписывал. После этого вмешиваться в разработку он не мог.
Это имхо из личного опыта
customtema
05.11.2018 10:30Знаю таких двоих. Один из Москвы, другой из Питера. Проекты идентичные, не сговариваясь, оба мне кровушки попили и нервушки изрядно потрепали, 2014-2016.
Интересно, вам попался один из этих двух, или третий?..
lagudal
05.11.2018 10:55Гос не гос, равно как и страна, мне кажется, роли не играет. Определенный тип заказчиков.
У меня в начале 2015 года была ситуация. Германия, маленькая семейная фирма, очень интересный на первый взгляд проект — нужет вебшоп в очень специфической тематике.
Я на тот момент между работами, хозяин хочет все только чтобы я был штатной единицей его фирмы, 40 часов в неделю. Так как «ты должен быть всегда рядом, потому что у меня столько идей всегда, что я должен их незамедлительно озвучивать».
Все это вылилось в то, что после нескольких прототипов и его многочисленных и постоянно меняющихся хотелок я уже не мог этого всего выносить, и предложил ему промежуточный вариант, что то вроде лендинга, пока все его пожелания не сформируются в четкий задокументированный проект…
В результате, спустя почти 4 года, у него, кроме того самого лендинга, что я сваял за пару недель и что должен был просуществовать не дольше года, ничего так и нет. Как уже почти 3 года нет и меня у него на фирме…
А идею до сих пор считаю очень даже неплохой.
teemour
05.11.2018 11:51Исходя из описанного, думаю, вы были неготовы к изменениям. Ну сделали бы вы вашу систему и она в тот же день умерла, потому что вы не можете её развивать. Это с точки зрения архитектуры. С точки зрения управления проектом и контрактных отношений, видимо, не там была проведена граница ответственности. Вмешиваться в детали заказчик, может быть, и может, но вы должны быть готовы оба.
Это независимо от того как отжигал заказчик
fotofan
05.11.2018 12:21+2Заказчику просто нравится ковыряться в проекте собственными руками. Так он себя ощущает творцом, не будучи таковым. Ведь чем больше он него лезет, включая технические моменты реализации, тем больше у него появляется ощущение, что проект он выносил буквально на руках (о чем и будет рассказывать друзьям в бане). Для этого подобным заказчикам нужен определенный тип исполнителя
docadept
05.11.2018 13:07Судя по всему, это должен был получиться клон diagnose.me, дизайн очень даже неплох был в прототипах, но вот идея… Ах да, еще прием к врачу планировалось реализовать, кроме консультаций, но и такое уже есть — агрегаторы всяческие с записью.
mekhaga Автор
05.11.2018 13:08да, есть, но ключевая особенность нашего проекта была возможность получать консультации не как инфо услугу(яндекс здоровье, док док и тп) а как медицинскую услугу.
mSnus
05.11.2018 14:52+1Если заказчик вам за все заплатил — он вообще лапочка. И имеет право все наработки выкинуть. Если бы прокидал — другая история!
А вот то, что он явно вынужден был пойти на отчаянные меры, и в результате ему оказалось проще рулить програмером самому, а потом и вовсе пилить Тильду — значит, где-то вы в общении сильно накосячили, перестали его слушать или не смогли прийти к согласию.
По дизайну — извините, это не дизайн. Это довольно детально проработанный прототип, или начальная стадия, но готового дизайна там не видно. Плюс несколько серьезных косяков: вы делаете сайт, достаточно большой частью аудитории которого будут люди с не лучшим зрением, но набираете большое количество текстов мелким шрифтом. Или, например, что будет с дизайном личного кабинета, если понадобится достаточно вероятное действие — добавление оплаты через Яндекс.Деньги?
Ну и в целом, засветить вот так заказчика — очень другой тон.
Если он выполнил перед вами все финансовые обязательства, а других не было, и решил переделать проект у других дизайнеров — чтобы продать идею инвесторам или отчитаться перед министерством, например — да мало ли! — то вы им можете таким образом довольно сильно подгадить.
mekhaga Автор
05.11.2018 15:13А вот то, что он явно вынужден был пойти на отчаянные меры, и в результате ему оказалось проще рулить програмером самому, а потом и вовсе пилить Тильду — значит, где-то вы в общении сильно накосячили, перестали его слушать или не смогли прийти к согласию.
Проще рулить? А может дешевле платить напрямую программисту, чем агентству? Вы об этом подумали? В обход нас заказчик написал программисту не ради общения, а ради экономии. Это во первых. Во вторых, общение у нас было более чем адекватное, за всю работу было порядка 20 встреч в разных местах где мы обсуждали не только проект, но и вели многие другие разговоры. Если вы сомневаетесь в нашей компетентности(к слову говоря да, местами были некомпетентны), то что вы скажите на то, что в ходе работы сменились 2 эксперта в медицинской сфере? Они тоже были некомпетентны?
По дизайну. Странно что его не оценили только вы, ведь другие комментаторы говорили об обратном.
Добавление яндекс.денег причем тут вообще? Оплата внедрена была в момент заключения и подтверждения консультации.
Проект от частного лица а не государственного заказчика, просто размах на проект федерального уровня. Мы поделились лишь кейсом о нашем проекте, где реальный опыт. У нас нету цели очернить кого-нибудь или подгадить.DrPass
05.11.2018 15:18Проще рулить? А может дешевле платить напрямую программисту, чем агентству? Вы об этом подумали? В обход нас заказчик написал программисту не ради общения, а ради экономии.
А что значит «в обход вас»? Вы были третьей стороной, программиста привлекали в проект не вы? В моём понимании программист должен был послать заказчика, кхм, обратно к вам. Это fair play любого сотрудничества.mekhaga Автор
05.11.2018 15:21на ошибках учатся, что я могу сказать, мы многое вынесли из этого проекта
mSnus
05.11.2018 17:53+1Простите, если вы. агентство, то откуда у клиента вообще контакты программиста? Тем более, если это не ваш программист? На то и менеджеры, чтобы с клиентом общались только те, кому можно, и те, кто это умеет.
Про "экспертов в медицинской сфере" я вообще не очень понял, при чем они тут. Вы сайт для экспертов-медиков делали? Если нет, то вам скорее нужна помощь не кардиолога или стоматолога, а главврача. Зачем их меняли — из вашего описания неясно.
По дизайну вообще не хотел придираться, т.к. вы об этом не просили. Поэтому написал только в общем, с точки зрения заказчика — на готовый дизайн это не очень тянет, я бы такую работу не принял.
Про "подгадить" — получается, что вы засветили и имя, и идею заказчика до полной реализации. Странно, что у вас никакого NDA не подписано, видимо, заказчик не очень опытный. Но, даже если он не запретил это прямо через NDA, хороший тон — заменить логотипы, а лучше — ещё и заменить врачей на, например, сантехников или репетиторов. Статья от этого ничего не потеряла бы.
ganqqwerty
05.11.2018 16:30+2У меня ощущение, что заказчик вас просто подавил своей властью, которая при этом сочеталась с расхлябанностью с обеих сторон. Гибкость гибкостью, а новых требований по ходу проекта должно становиться меньше, а работающего продакшен кода — больше. Если не становится — нужно проявлять волю и указывать на проектировочные документы, брать и отказывать в новых фичах.
«Совещания становились брейнстормом» — ну дык, а кто делал план совещания? Кто стукал линейкой по рукам всех, кто идет не по плану совещания?
Аналогично с вашими идеями — ну что это значит, «категорический отказ». Отказ бывает мотивированным чем-то.
Ну и оплата программисту в обход компании — это просто цирк, всецело лежащий на совести руководителя проекта. Руководитель не только не наладил коммуникации, у него в команде просто отсутствует субординация.
В чем вы большие молодцы — это в том, что правильно организовали схему оплаты и получили свои денежки. Иначе было бы совсем обидно.
AGARTY
05.11.2018 23:09Как же это знакомо.
Помнится портал делал, очень крупный, с превосходной заявкой на будущее. Он начал зарабатывать еще до того, как был готов сайт. Многие были в нем заинтересованы. Но вот вместо запуска малой версии, руководство решило менять все и вся. Дошло до того, что во вт. я получал задание, просто забивал на него, а в чт. это задание отменялось и перерабатывалось в другое. И не потому, что я забивал. Оно бы изменилось в любом случае, и я решил не тратить время на бесполезный код. И так практически каждую неделю.
Посчитал свои затраты, сказал «ребята я все», передал полностью управление другому разрабу, получил гонорар, где полезный выхлоп составил чуть более 7к (остальное это приезды, обеды и прочее), и удалился восвояси. Потом тоже сделал второй разраб. Третий…
Проект умер.mekhaga Автор
06.11.2018 14:40Знакомая ситуация. Сейчас ровно то же самое с этим проектом… к сожалению
achekalin
06.11.2018 14:03Почему я дергаюсь, видя префиксы «рос» и «нац»? Ладно, что американская калька (все эти «национальные» штуки), так еще и в голове подсознательная четкая уверенность, что это нифига не официально серьезное дело, а очередное очковтирательство.
Рад бы ошибиться и увидеть обратный пример!
Про «заказчика» как-то вскользь все время, но все же интересно, за чей счет работы-то велись — это мы же с вами из налогов оплатили, или это коммерческое начинание?mekhaga Автор
06.11.2018 14:38К счастью это не гос.заказчик. Это физическое лицо и ничьих налогов тут не было:)
dag_tech
06.11.2018 14:37По моему мнению, исходно в статье очень корректно и мягко (и, возможно, с обидой от того, что не оправдались несколько наивные ожидания) описан подход российских окологос- и гос-заказчиков, тем более в сфере здравоохранения, к реализации ИТ-проектов.
(Сразу примечание-оговорка — нужно делить гос- и окологос-. Для представителей гос-заказчиков существуют хоть какие-то формы контроля и вероятность ответственности за «суммарно понесенный эффект» — выговор в личном деле пожизненно не приятен, также можно и под горячую руку попасть (никто же не знает, какая жалоба и по какому вопросу «выиграет лотерею», например, на прямой линии). Для окологос- о какой-либо ответственности речь не идет, потому что комплексные договоренности о «вертикали» распределения бюджета размывают понятие ответственности, распределение бюджета уже согласовано задолго до того, как менеджеры Исполнителя провели 1-ую встречу с представителями окологос-.
Попробую систематизировать некоторые взаимодополняющие проблемы реализации ИТ-проектов в таких заказчиках:
1) Бесконечный цикл уточнения и «переосмысления» требований — с многократными (через квартал-полгода) возвратами к аспектам, которые раньше эти же люди категорически отвергли;
2) Пункт 1 дополняется категорическим нежеланием (или неспособностью?) не то что читать, а хотя бы просматривать документацию — то что бюрократически называется «согласовать в рабочем порядке» принципиально не работает, а кроме этого, принципиально не работают и попытки согласовать (и попросить документ, решение о согласовании, протокол....) документацию в официальном порядке — направлением официальных писем, получением номеров входящих, напоминаниями назначенным исполнителям, что нужно бы рассмотреть документацию и т.п.;
Насчет нежелания работать с документацией — много ярких примеров с просьбами сделать выжимки из выжимок из выжимок — … «все равно больше двух абзацев читать не будем...»
3) Подчеркнуто-наигранно-выставляемое-на-показ отсутствие элементарных представлений об информационных технологиях. Например, когда после полугодовых итераций наконец-то хоть как-то договорились об основных сущностях и процессах, демонстрируемый прототип интерфейса (сделанный чтобы хоть как-то зафиксировать договоренности) вызывает неадекватный восторг — «о! все работает! отлично ребята — долго запрягали, но наконец-то сделали...» и попытки сказать что еще конь не валялся в части детализации схемы данных, бизнес-логики, оценок нагрузки, и прочих аспектах, наталкиваются на аргумент — «ну да ладно, за пару недель сделаете? а мы вам уже не нужны...»;
4) Еще один очень важный момент — в таких заказчиках цикл принятия решений в большинстве случаев оказывается длиннее цикла смены лиц, принимающих решения
— что дополнительно усугубляет п. 1.
Ну и так далее — об этом можно написать отдельную статью.
Справедливости ради необходимо отметить, что:
1) все реальные проекты в области здравоохранения и социальной сферы отличаются высокой сложностью (сущность «пациент» гораздо сложнее сущности «гражданин», высокая противоречивая зарегулированность и т.п.)
2) подобные проблемы есть не только у нас — пример с провалом ИТ-проекта Обамы известен всем; еще подобрана информация здесь www.cnews.ru/articles/2018-04-25_velikobritaniyasshaavstraliya_samye_epichnye_provaly_zarubezhnyh
alexsibtone
«Слезы радости» застили глаза после прочтения. Полезно знать, что род подобных заказчиков не только занимается недвижимостью и доставкой грузов, а и пробует себя в медицине. Дас, все грустно.