Как превратить федеральный проект в сайт-визитку? Почти подробная инструкция

Когда заказчик впервые обозначил идею своего проекта — Роснацздрав, она показалась очень интересной. Собственно, так оно и было.

Только представьте, федеральная ассоциация, которая объединит в себе медицинские организации со всей России, позволит простым пациентам из любой точки страны, получить онлайн-консультацию профильного специалиста, скажем, из Москвы, а при необходимости записываться и на реальный прием.

На начальной стадии могло немного насторожить, что описанная выше концепция и была сутью ТЗ. Но проект интересный и амбициозный — поэтому принять участие в формировании более адекватного ТЗ было даже интересно.

В итоге оно было сформировано. Предполагалось создать максимально понятную оболочку продукта в виде сайта, где клиент, предоставив минимальный набор параметров, попадал в личный кабинет, который и был основной проекта.

Помимо этого для привлечения организации в ассоциацию предлагалось участие последних в законотворческой инициативе. Проще говоря, если собрать несколько крупных организаций в одну ассоциацию, вполне можно лоббировать законы, которые помогут осуществлять их деятельность.

Заказчик, правда, очень боялся использовать слово “лоббировать”, хотя в нём нет ничего негативного, и даже попросил исключить его из презентации проекта, но об этом позже.

Личный кабинет, точнее личные кабинеты, представляли собой многоуровневую систему взаимодействий между врачом, пациентом, организацией, а также между врачами разных организаций.

Когда ТЗ было утверждено — началось создание прототипов и логической структуры проекта, работа была поистине огромная — сотни страниц прототипов, которые, помимо того, что должны были отображать визуальное структуру — так ещё являлись и своего рода ТЗ для будущего программирования.

О том, что ТЗ было предварительным, мы на тот момент не знали. К счастью (ну, как выяснилось позже, к несчастью) заказчик предпочитал личные встречи для обсуждения проекта. Обычно — это даже лучше, позволяет ускорить процесс, и согласовать отдельные детали в режиме “plug&play”.

Но, увы, каждая встреча становилась не рубежом, после которого должен был начаться следующий этап разработки, а мозговым штурмом, в духе: “А давайте вот так сделаем!”, “А вот мне тут идею подкинули”. В итоге уже готовые прототипы приходилось переделывать, причем, учитывая достаточно прямую взаимосвязь всех элементов кабинета — небольшая, по виду, правка, могла привести к тому, что изменять приходилось практически всё. Наверное, и не стоит говорить — что заказчик считал правки такого рода обычным рабочим процессом, и увеличивать смету целесообразным не считал.

Практически на каждой встречи выяснились новые обстоятельства, вроде невозможности определенных видов консультаций, например консультации “врач-пациент” по законам Российской Федерации, и необходимости для пациента идти к врачу в своём городе, и в его присутствии проводить онлайн-консультацию. Причём последний должен был быть членом ассоциации для непосредственной возможности использования личного кабинета и самого ПО для проведения сеанса TrueConf, интегрированную в личный кабинет.

Отдельно стоит упомянуть про экспертность, и ее значимость при разработке проектов. Первое время, на встречах присутствовал достаточно известный врач-кардиолог, он, что называется, ратовал за продукт, а не за его оболочку. Предлагал действительно интересные идеи, и что важнее — считал более важным реальный запуск проекта, чем его бесконечную переделку «на коленке». Учитывая, что он настоящий врач, казалось бы, к его советам надо прислушаться. Но, судя по тому, что после 3-ей встречи он из проекта выбыл — экспертность посчитали не самым важным параметром при разработке. Что забавно — вместо кардиолога, на одну из следующих встреч, пришёл уже стоматолог.

В итоге было подготовлено две итерации дизайна, согласование которых, к счастью, прошло без особых проблем.
А дальше начался самый настоящий треш и угар, заказчик, видимо не понимая как именно происходит процесс программирования, решил связаться с программистом сам, в обход нас, и не просто связаться, но и начать давать ему новые вводные напрямую, а позже решил и вовсе платить ему напрямую, но при этом, продолжая работать с нами.

В итоге, сверстанный и выкаченный проект оказался в стазисе, потому что программная часть была построена на новых неожиданных идеях, которые никто до нас не донес. Программист, видимо, посчитал, что это сделал заказчик — а заказчик посчитал, что всё автоматически интегрируется и будет работать, какие правки не давай.

Несмотря на то, что мы продолжали сотрудничество, подготовили полноценную презентацию проекта, макеты визиток сотрудников и компаньонов заказчика (которые, по ходу работы, менялись два раза) — огромный проект так и не смог взлететь.

Ещё на начальном этапе мы предлагали добавить проект на ФРИИ (Фонд Развития Интернет-Инициатив), проработать слабые места, узнать дополнительные экспертные мнения — но заказчик эту идею отверг. Он и так знает, что делать. Примечательно это тем, что несколько месяцев спустя, в общем чате мы увидели сообщение в духе: «А почему мы ФРИИ не использовали?»

В итоге, в каком-то отчаянном шаге, заказчик нашел дизайнера, который сделал абсолютно странный, и не соответствующий логике дизайн, а после, так и вовсе нанял компанию (мы так и не выяснили какую), которая превратила огромный федеральный проект в небольшой сайт-визитку на тильде, в котором даже не потрудились подобрать качественные изображения, а кнопка «Личный кабинет» в углу экрана так и осталась кнопкой ведущий в никуда.

Всегда печально, когда интересный проект не доходит до реализации, но еще печальнее, когда уже почти реализованный проект умирает, потому что заказчик так и не смог понять, что он хочет, а новых замечательных идей, с каждым разом было всё больше.

Как итог, сайт-визитка вместо федерального многофункционального портала.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 60

    +8
    «Слезы радости» застили глаза после прочтения. Полезно знать, что род подобных заказчиков не только занимается недвижимостью и доставкой грузов, а и пробует себя в медицине. Дас, все грустно.
      +9
      Я бы вообще не стал работать с государственными организациями.
      Для меня это как табу.

      Странно, что некоторые себе позволяют видеть «Роснац...» в виде «заказчика».

      Шли бы они в пень, себе потом будет дороже с такими работать.
      Слишком много вокруг примеров, господа.
        +6
        Это не государственный заказчик. Это какая-то мутная «ассоциация» с названием, похожим на что-то «государственное».
          +4
          Да тем более.
          Мы столько секса поимели с «интерсекьюритифорум», что никому такого не пожелаю.
          Оно даже гуглится — можете посмотреть.

          Всё, что косит под государственную структуру, всё, что в составе заказчиков имеет государственные структуры — ровным строем идёт в пень.
          Иначе, у вас будет секс на каждом этапе согласования, создания и внедрения.

          Проще частникам сделать интернет-магазин керамической плитки.
          +5
          Да и среди негосударственных таких миллион. Но как по мне, тут и разработчик наделал ошибок со своей стороны. Заказчику-то несложно сказать «а давайте всё переделаем нафиг». Но разработчик в ответ на это не должен всё переделывать нафиг (ещё и без увеличения сметы), а объяснить заказчику, сколько и почему это ему будет стоить, и по деньгам, и по срокам.
          А ещё, пункт о разрешении таких ситуаций (а-ля «в случае изменений уже разработанного функционала такие работы выполняются как дополнительные, за отдельную плату»). необходимо изначально включать в договор с заказчиком. Благо, он обычно даже с самыми сложными заказчиками не вызывает вопросов.
            +6
            «Если вы не любите людей — значить вы просто не умеете их готовить»(с)Людоед.
            Нет, государственный заказчик — это особенный заказчик типа «араб», к которому нужен особенный подход. Особенность в том, что с ним ни в коем случае не надо пытаться «дружить», надеясь на дальнейшее сотрудничество и партнёрство (ибо сами знаете насчёт страны...), а стараться брать оплату за каждый взбрык. Переделка макета — столько-то, реализация идеи — столько-то, реализация глупой идеи — в двойном размере, ложный вызов менеджера по работе с клиентами — гоните оплату, барин. Итоговый проект не взлетит с вероятностью 90%, это нужно просто принять как данность. Но главное — самим в пролёте не остаться по деньгам.
              +1
              Тут нужно понимать специфику.
              У этих людей нет ни капли заинтересованности в выпуске продукта. Большие дяди собрались и решили запилить проект, выбили бюджет и спустили задачу более мелким дядям (задачу спустили а цели, что важно, так и остались в голове у больших дядь, если вообще не были забыты).
              А далее стандартный сценарий — есть бюджет, есть задачи и есть люди, которым сказано копать от забора до обеда они и капают от забора до обеда. Их главная цель (если не разводить холивары про откаты) — соблюдать спущенные с верху сроки и деньги + получать ЗП. Интереса в запуске продукта уже нет.
              Тоесть если Вы хотите заработать относительно легкие деньги и у вас команда чуть ниже среднего (там явно не нужны супер звездная команда разработки, дизайнеры от бога или не спящие ночами продакт овнеры) велкам на тендеры к гос сектору или внутренние проекты крупных корпораций (там примерно творится тоже самое что и в гос структурах)
              0
              1. От постоянных правок помогают гибкие методологии. А вы, похоже, решили всё и сразу задизайнить, а потом реализовать.
              2. Не совсем понятна ваша роль. За что отвечали в проекте?
                +1
                Можно узнать подробнее про гибкую методологию? Мы сначала сделали кучу прототипов, а потом дизайн.

                Я и проджект и дизайнер проекта
                  +4
                  https://ru.wikipedia.org/wiki/Гибкая_методология_разработки

                  Исходя из вопроса, я начинаю догадываться о причинах описанного развития проекта.
                    +6
                    Собственно, статья не просто про провал проекта, а про некомпетентность всех сторон — и прежде всего, автора статьи.
                      0
                      Очень интересно на чем основан ваш аргумент? В каком месте мы были некомпетентны? Все было в срок, соответствовало все ТЗ, все этапы были согласованы. А оценивать уровень компетентности по постоянным доработкам заказчика, это как-то… глупо
                        +10
                        Есть такое понятие: управление ожиданиями заказчика. И вот тут вы похоже не справились, как ПМ. Потому как работа ПМ, в том числе, заключается в том, чтобы предложить такой подход, который бы учитывал постоянные правки. Я не зря упомянул гибкие методологии. Они действительно могут помочь. И когда человек, который называет себя ПМ, с одной стороны, спрашивает: что это такое, agile? А с другой стороны, сваливает неудачу проекта на заказчика, который постоянно приносит правки, возникают резонные сомнения в его компетентности.
                          –6
                          Ну в статье написано, что на все наши идеи были категоричные отказы. Какое бы вы решение могли предложить?
                            +5
                            Самый правильный вариант в таком случае — каждое изменение или отступление от ТЗ — это деньги+время. Если заказчик и на такие ваши «идеи» отвечает категоричным отказом, то сразу очевидно, что ничего не получится.
                            0
                            Гибкие методики это не серебренная пуля, они никак не помогут при работе с заказчиков вида — а давайте все переделаем. Вы неделю пилите пачку мелких функциональностей, а на следующем совещании вам говорят — вы ничего из того, о чем мы договаривались не сделали, мы обратимся в другую компанию, а с вами посоветуем никому дел не иметь.

                            В данном случае только метод «каждая работа должна оплачиваться» без попыток «подружиться» с клиентом.
                              0
                              1.
                              Гибкие методики это не серебренная пуля

                              Да, согласен, agile — не серебряная пуля. Но, он может сильно помочь в описанной ситуации, если уметь им пользоваться.

                              2.
                              они никак не помогут при работе с заказчиков вида — а давайте все переделаем.

                              Они как раз на такое и рассчитаны. Закончили спринт (допустим, здесь и далее у нас Scrum). А дальше — хоть с нуля, хоть переноси с веб на десктоп. Главное, спланировать на следующий спринт.

                              3.
                              Вы неделю пилите пачку мелких функциональностей, а на следующем совещании вам говорят — вы ничего из того, о чем мы договаривались не сделали, мы обратимся в другую компанию, а с вами посоветуем никому дел не иметь.

                              «Гибкая методология» — не равно «отсутствие требований, плана и т.п.». Нельзя работу работать в спринте и в итоге сделать не то, что было поставлено, как цели на спринт, а что-то другое. И договорённости все фиксируются. И закзачик сам принимает участие в определении целей.

                              4.
                              В данном случае только метод «каждая работа должна оплачиваться» без попыток «подружиться» с клиентом.

                              Одно другому не мешает. Работа должна быть оплачена всегда.
                            0

                            На доработки заказчика можно соглашаться только с подписанным Change Order. Все остальное (включая чаты, емейлы, личные разговоры) — это не документы, к делу не подошьешь. Соглашаться на доработки бесплатно и не задокументированно — путь к закономерному провалу.

                              +1
                              Да нет же, все это было за доплату, естественно. Каждая доработка оплачивалась и подписывались промежуточные акты.
                              0
                              С девятого абзаца и далее везде.
                          +1
                          Вот это неправильно. В любой момент времени у вас должна быть готовая версия сайта, которую можно взять и использовать на производстве. Бесконечные не работающие прототипы и ковыряние в стадии пре-релиза — это плохо.
                          +3
                          С некоторыми заказчиками гибкие методологии вам не помогут. Например с гос заказом вы по закону обязаны работать только по waterfall с четкими этапами и никак иначе. Внутрениие процессы организуйте как вам угодно, но с заказчиком извольте только через waterfall.
                          Ну и если заказчик крупный и не гибкий, то он будет навязывать свой подход мотивируя это «мы так не работаем», «у нас так не делается», «так нам не согласуют сверху»… Некоторые корпорации еще менее гибкие чем гос структуры.
                            0
                            Я, как бы, и не спорю. Гибкие методологии — не панацея. Где-то WF работает. Ничего плохого в этом нет.
                            Просто у ТС описана ситуация, когда в проекте идут постоянные правки и изменения по инициативе заказчика. И да, в комментариях всплыло, что заказчик оплачивал изменения. А вот ПМ не смог работать в таком режиме.
                          +1
                          Дел
                            +4
                            Вопрос один — вам заплатили за вашу работу?
                              +1
                              Да
                                0
                                А выкладывание дизайнов в паблик — это ОК с юридической точки зрения после завершения проекта? Правда интересно.
                                  0
                                  Ну это не исходники, это просто картинки, превью макетов + никаких NDA и никакой передачи исключительных авторских прав не было. Поэтому — это ОК.
                              +1
                              По моему опыту, в таких проектах надо сначала внимательно выслушать и опросить представителей стороны заказачика, провести с ними несколько встреч. Но потом уже писать ТЗ самому, никого больше не слушая, давить авторитетом, и говорить что ты лучше знаешь как реализовать такой проект. Конечно, по ходу написания ТЗ нужно задавать заказчику появляющиеся вопросы, но ни в коем случае не давать ему влезать в составление проекта. Включайте режим «Мы вас выслушали, мы профессионалы, теперь мы объясняем что и как надо делать.»
                              В противном случае проект практически гарантированно утонет в обсуждениях, новых «гениальных» идеях, и бесконечном потоке псевдоэкспертов со стороны заказчика.
                                +1
                                Это создает другой риск — после сдачи проекта вам говорят «проект не отвечает нашим потребностям», а на все ваши возражения вы услышите «ну мы же вам говорили, а вы не слушал»
                                +4
                                Заказчик бабло отмыл)
                                  +3
                                  Все это похоже на имитацию бурной деятельности с последующей передачей проекта в карманную фирму с откатом.
                                  +4
                                  Когда ТЗ было утверждено — началось создание прототипов и логической структуры проекта, работа была поистине огромная — сотни страниц прототипов, которые, помимо того, что должны были отображать визуальное структуру — так ещё являлись и своего рода ТЗ для будущего программирования.

                                  О том, что ТЗ было предварительным, мы на тот момент не знали.


                                  суть (с) ТМ
                                    +1

                                    Стандартная история любого государственного проекта в "информатизации здравоохранения". Система была как бы предназначена для врачей и пациентов. Так надо было делать её для врачей и пациентов. Второй исполнитель абсолютно правильно понял, что систему надо делать для заказчика и идеально справился.

                                      0
                                      потому что заказчик так и не смог понять, что он хочет
                                      ничего личного, но у вас тоже не хватило ума рассказать заказчику, что каждое изменение требует времени и денег. Каждая его хотелка о которой не договаривались — аналогично. У вас были отличные возможности сделать это на личных встречах — рассказывать такое проще лично, чем в почте. Но переговоры с заказчиком и разговор на языке заказчика — это такая же важная часть проекта как и само программирование.
                                      А в вашем случае оно(переговоры) было даже важнее чем само программирование, потому что вы с заказчиком друг друга не поняли. Можно было даже не напрягать программиста.
                                      И проблема как в статье не зависит — государственный ли заказчик, или нет. Везде есть такие самодуры, которые «всё знают как надо», но к ним тоже нужен подход чтобы всё объяснить на его языке, на крайняк на языке денег.
                                        +1
                                        Я так понимаю, что ТЗ по договору должны были вы сделать. Это нормально, за это часто даже отдельная строка в смете существует. Но в итоге вы его сделали? Пишите, что оно было утверждено, но судя по рассказу им никто не пользовался. Или предполагалось, что оно будет оформлено окончательно, когда будет сделан проект? ТЗ — это гарантия баланса интересов обеих сторон. Если оно утверждено, то за оплату допработ можно уже не беспокоиться. Даже за оплату доработки ТЗ, потому что это отдельная работа. А иначе заказчик лишь воспользуется ситуацией. Причём «не со зла». Он же не профессионал, он не знает как это работает. А вы профессионалы. И позволили ему вообще всё за бесплатно.
                                          0
                                          Вы абсолютно правы. И это работает, когда заказчик адекватный.

                                          А когда персонаж маскирует паранойю развитым интеллектом, при этом он сам ее не ощущает, и считает свои мысли и действия последовательными, свое мнение — истиной в последней инстанции. Тут ТЗ мало помогает. Сразу в суд.
                                            0
                                            Не стоит так уж судов бояться. В России это просто часть бизнес-процессов. Некоторые платят только по суду. Некоторые не понимают либо не идут на компромисс, пока иск не получат. С госзаказчиками в этом плане есть фича. Если идёт где-нибудь третий квартал года уже, то можно неплохо так шантажировать. У них должен быть освоен выделенный им бюджет, то есть все деньги должны быть закрыты выполнением до конца года. Что осталось — должны вернуть обратно в бюджет. За это их накажут, а повторно выклянчивать очень сложно. Поэтому они становятся очень сговорчивыми, когда явно не правы.

                                            Из личного опыта. Сейчас, возможно, правила игры поменялись, но несколько лет назад в ходу была следующая схема. Стройка. Сроки никогда не соблюдаются. Но если напишешь реальные сроки, то тендер не выиграешь, а госзаказчику деньги на долгострой не выделят. В общем, под конец года «обнаруживается», что сдать объект в ближайшем будущем не получится. Подписывается допник с подрядчиком, по которому ему закидывают дополнительный аванс на десятки/сотни миллионов, но с условием, что если он их не отработает в ближайшие три месяца (а он их не отработает физически чисто), то он аванс вернёт обратно. Все счастливы: госзаказчик освоил бюджет, а подрядчик получил халявный многомиллионный кредит на несколько месяцев. Вин-вин.

                                            К чему этот пример… Если госзаказчик неадекват и явно не прав, а близится конец года, то можно рубить концы (разумеется, правильно рубить, и подстраховавшись правильными бумажками), прекращать работы и идти в суд. Чем ближе к концу года, тем больше будет истерики. Но зато компромисс найдётся быстро.
                                            0
                                            нет, тз утвердили, начали делать, в ходе работ возникали уже доработки, за которые заказчик естественно платил
                                              0
                                              Специфика работы с врачами в чистом виде тут( Мне пришлось разрабатывать для врачей несколько программ (заказчик — частная компания). Как правило, лишь отдельные специалисты (часто кстати кардиологи) ставят адекватные задачи и способны понять, когда им говоришь, что так делать нельзя. Остальным надо говорить «это технически невозможно» — так вы сбережете себе нервы и время. В итоге пришел к тому, что проводил несколько встреч с обсуждением деталей ТЗ, которое затем писал сам, а заказчик знакомился и подписывал. После этого вмешиваться в разработку он не мог.
                                              Это имхо из личного опыта
                                            +1
                                            Знаю таких двоих. Один из Москвы, другой из Питера. Проекты идентичные, не сговариваясь, оба мне кровушки попили и нервушки изрядно потрепали, 2014-2016.

                                            Интересно, вам попался один из этих двух, или третий?..
                                              +2
                                              Гос не гос, равно как и страна, мне кажется, роли не играет. Определенный тип заказчиков.
                                              У меня в начале 2015 года была ситуация. Германия, маленькая семейная фирма, очень интересный на первый взгляд проект — нужет вебшоп в очень специфической тематике.
                                              Я на тот момент между работами, хозяин хочет все только чтобы я был штатной единицей его фирмы, 40 часов в неделю. Так как «ты должен быть всегда рядом, потому что у меня столько идей всегда, что я должен их незамедлительно озвучивать».
                                              Все это вылилось в то, что после нескольких прототипов и его многочисленных и постоянно меняющихся хотелок я уже не мог этого всего выносить, и предложил ему промежуточный вариант, что то вроде лендинга, пока все его пожелания не сформируются в четкий задокументированный проект…
                                              В результате, спустя почти 4 года, у него, кроме того самого лендинга, что я сваял за пару недель и что должен был просуществовать не дольше года, ничего так и нет. Как уже почти 3 года нет и меня у него на фирме…
                                              А идею до сих пор считаю очень даже неплохой.
                                                0

                                                Хороший урок, для вас.

                                                  +1
                                                  Роснацздравнадзор…
                                                  сколько же их расплодилось этих Абырвалгов…
                                                    0
                                                    Исходя из описанного, думаю, вы были неготовы к изменениям. Ну сделали бы вы вашу систему и она в тот же день умерла, потому что вы не можете её развивать. Это с точки зрения архитектуры. С точки зрения управления проектом и контрактных отношений, видимо, не там была проведена граница ответственности. Вмешиваться в детали заказчик, может быть, и может, но вы должны быть готовы оба.
                                                    Это независимо от того как отжигал заказчик
                                                      +2
                                                      Заказчику просто нравится ковыряться в проекте собственными руками. Так он себя ощущает творцом, не будучи таковым. Ведь чем больше он него лезет, включая технические моменты реализации, тем больше у него появляется ощущение, что проект он выносил буквально на руках (о чем и будет рассказывать друзьям в бане). Для этого подобным заказчикам нужен определенный тип исполнителя
                                                        0
                                                        Судя по всему, это должен был получиться клон diagnose.me, дизайн очень даже неплох был в прототипах, но вот идея… Ах да, еще прием к врачу планировалось реализовать, кроме консультаций, но и такое уже есть — агрегаторы всяческие с записью.
                                                          0
                                                          да, есть, но ключевая особенность нашего проекта была возможность получать консультации не как инфо услугу(яндекс здоровье, док док и тп) а как медицинскую услугу.
                                                          +3

                                                          Если заказчик вам за все заплатил — он вообще лапочка. И имеет право все наработки выкинуть. Если бы прокидал — другая история!


                                                          А вот то, что он явно вынужден был пойти на отчаянные меры, и в результате ему оказалось проще рулить програмером самому, а потом и вовсе пилить Тильду — значит, где-то вы в общении сильно накосячили, перестали его слушать или не смогли прийти к согласию.


                                                          По дизайну — извините, это не дизайн. Это довольно детально проработанный прототип, или начальная стадия, но готового дизайна там не видно. Плюс несколько серьезных косяков: вы делаете сайт, достаточно большой частью аудитории которого будут люди с не лучшим зрением, но набираете большое количество текстов мелким шрифтом. Или, например, что будет с дизайном личного кабинета, если понадобится достаточно вероятное действие — добавление оплаты через Яндекс.Деньги?


                                                          Ну и в целом, засветить вот так заказчика — очень другой тон.


                                                          Если он выполнил перед вами все финансовые обязательства, а других не было, и решил переделать проект у других дизайнеров — чтобы продать идею инвесторам или отчитаться перед министерством, например — да мало ли! — то вы им можете таким образом довольно сильно подгадить.

                                                            0
                                                            это жалобная книга?
                                                              0
                                                              А вот то, что он явно вынужден был пойти на отчаянные меры, и в результате ему оказалось проще рулить програмером самому, а потом и вовсе пилить Тильду — значит, где-то вы в общении сильно накосячили, перестали его слушать или не смогли прийти к согласию.



                                                              Проще рулить? А может дешевле платить напрямую программисту, чем агентству? Вы об этом подумали? В обход нас заказчик написал программисту не ради общения, а ради экономии. Это во первых. Во вторых, общение у нас было более чем адекватное, за всю работу было порядка 20 встреч в разных местах где мы обсуждали не только проект, но и вели многие другие разговоры. Если вы сомневаетесь в нашей компетентности(к слову говоря да, местами были некомпетентны), то что вы скажите на то, что в ходе работы сменились 2 эксперта в медицинской сфере? Они тоже были некомпетентны?

                                                              По дизайну. Странно что его не оценили только вы, ведь другие комментаторы говорили об обратном.

                                                              Добавление яндекс.денег причем тут вообще? Оплата внедрена была в момент заключения и подтверждения консультации.

                                                              Проект от частного лица а не государственного заказчика, просто размах на проект федерального уровня. Мы поделились лишь кейсом о нашем проекте, где реальный опыт. У нас нету цели очернить кого-нибудь или подгадить.
                                                                0
                                                                Проще рулить? А может дешевле платить напрямую программисту, чем агентству? Вы об этом подумали? В обход нас заказчик написал программисту не ради общения, а ради экономии.

                                                                А что значит «в обход вас»? Вы были третьей стороной, программиста привлекали в проект не вы? В моём понимании программист должен был послать заказчика, кхм, обратно к вам. Это fair play любого сотрудничества.
                                                                  0
                                                                  на ошибках учатся, что я могу сказать, мы многое вынесли из этого проекта
                                                                  +1

                                                                  Простите, если вы. агентство, то откуда у клиента вообще контакты программиста? Тем более, если это не ваш программист? На то и менеджеры, чтобы с клиентом общались только те, кому можно, и те, кто это умеет.


                                                                  Про "экспертов в медицинской сфере" я вообще не очень понял, при чем они тут. Вы сайт для экспертов-медиков делали? Если нет, то вам скорее нужна помощь не кардиолога или стоматолога, а главврача. Зачем их меняли — из вашего описания неясно.


                                                                  По дизайну вообще не хотел придираться, т.к. вы об этом не просили. Поэтому написал только в общем, с точки зрения заказчика — на готовый дизайн это не очень тянет, я бы такую работу не принял.


                                                                  Про "подгадить" — получается, что вы засветили и имя, и идею заказчика до полной реализации. Странно, что у вас никакого NDA не подписано, видимо, заказчик не очень опытный. Но, даже если он не запретил это прямо через NDA, хороший тон — заменить логотипы, а лучше — ещё и заменить врачей на, например, сантехников или репетиторов. Статья от этого ничего не потеряла бы.

                                                                  +2
                                                                  У меня ощущение, что заказчик вас просто подавил своей властью, которая при этом сочеталась с расхлябанностью с обеих сторон. Гибкость гибкостью, а новых требований по ходу проекта должно становиться меньше, а работающего продакшен кода — больше. Если не становится — нужно проявлять волю и указывать на проектировочные документы, брать и отказывать в новых фичах.
                                                                  «Совещания становились брейнстормом» — ну дык, а кто делал план совещания? Кто стукал линейкой по рукам всех, кто идет не по плану совещания?
                                                                  Аналогично с вашими идеями — ну что это значит, «категорический отказ». Отказ бывает мотивированным чем-то.
                                                                  Ну и оплата программисту в обход компании — это просто цирк, всецело лежащий на совести руководителя проекта. Руководитель не только не наладил коммуникации, у него в команде просто отсутствует субординация.

                                                                  В чем вы большие молодцы — это в том, что правильно организовали схему оплаты и получили свои денежки. Иначе было бы совсем обидно.
                                                                    0
                                                                    Как же это знакомо.

                                                                    Помнится портал делал, очень крупный, с превосходной заявкой на будущее. Он начал зарабатывать еще до того, как был готов сайт. Многие были в нем заинтересованы. Но вот вместо запуска малой версии, руководство решило менять все и вся. Дошло до того, что во вт. я получал задание, просто забивал на него, а в чт. это задание отменялось и перерабатывалось в другое. И не потому, что я забивал. Оно бы изменилось в любом случае, и я решил не тратить время на бесполезный код. И так практически каждую неделю.

                                                                    Посчитал свои затраты, сказал «ребята я все», передал полностью управление другому разрабу, получил гонорар, где полезный выхлоп составил чуть более 7к (остальное это приезды, обеды и прочее), и удалился восвояси. Потом тоже сделал второй разраб. Третий…
                                                                    Проект умер.
                                                                      0
                                                                      Знакомая ситуация. Сейчас ровно то же самое с этим проектом… к сожалению
                                                                      0
                                                                      Почему я дергаюсь, видя префиксы «рос» и «нац»? Ладно, что американская калька (все эти «национальные» штуки), так еще и в голове подсознательная четкая уверенность, что это нифига не официально серьезное дело, а очередное очковтирательство.
                                                                      Рад бы ошибиться и увидеть обратный пример!

                                                                      Про «заказчика» как-то вскользь все время, но все же интересно, за чей счет работы-то велись — это мы же с вами из налогов оплатили, или это коммерческое начинание?
                                                                        0
                                                                        К счастью это не гос.заказчик. Это физическое лицо и ничьих налогов тут не было:)
                                                                        0
                                                                        По моему мнению, исходно в статье очень корректно и мягко (и, возможно, с обидой от того, что не оправдались несколько наивные ожидания) описан подход российских окологос- и гос-заказчиков, тем более в сфере здравоохранения, к реализации ИТ-проектов.
                                                                        (Сразу примечание-оговорка — нужно делить гос- и окологос-. Для представителей гос-заказчиков существуют хоть какие-то формы контроля и вероятность ответственности за «суммарно понесенный эффект» — выговор в личном деле пожизненно не приятен, также можно и под горячую руку попасть (никто же не знает, какая жалоба и по какому вопросу «выиграет лотерею», например, на прямой линии). Для окологос- о какой-либо ответственности речь не идет, потому что комплексные договоренности о «вертикали» распределения бюджета размывают понятие ответственности, распределение бюджета уже согласовано задолго до того, как менеджеры Исполнителя провели 1-ую встречу с представителями окологос-.

                                                                        Попробую систематизировать некоторые взаимодополняющие проблемы реализации ИТ-проектов в таких заказчиках:
                                                                        1) Бесконечный цикл уточнения и «переосмысления» требований — с многократными (через квартал-полгода) возвратами к аспектам, которые раньше эти же люди категорически отвергли;
                                                                        2) Пункт 1 дополняется категорическим нежеланием (или неспособностью?) не то что читать, а хотя бы просматривать документацию — то что бюрократически называется «согласовать в рабочем порядке» принципиально не работает, а кроме этого, принципиально не работают и попытки согласовать (и попросить документ, решение о согласовании, протокол....) документацию в официальном порядке — направлением официальных писем, получением номеров входящих, напоминаниями назначенным исполнителям, что нужно бы рассмотреть документацию и т.п.;
                                                                        Насчет нежелания работать с документацией — много ярких примеров с просьбами сделать выжимки из выжимок из выжимок — … «все равно больше двух абзацев читать не будем...»
                                                                        3) Подчеркнуто-наигранно-выставляемое-на-показ отсутствие элементарных представлений об информационных технологиях. Например, когда после полугодовых итераций наконец-то хоть как-то договорились об основных сущностях и процессах, демонстрируемый прототип интерфейса (сделанный чтобы хоть как-то зафиксировать договоренности) вызывает неадекватный восторг — «о! все работает! отлично ребята — долго запрягали, но наконец-то сделали...» и попытки сказать что еще конь не валялся в части детализации схемы данных, бизнес-логики, оценок нагрузки, и прочих аспектах, наталкиваются на аргумент — «ну да ладно, за пару недель сделаете? а мы вам уже не нужны...»;
                                                                        4) Еще один очень важный момент — в таких заказчиках цикл принятия решений в большинстве случаев оказывается длиннее цикла смены лиц, принимающих решения
                                                                        — что дополнительно усугубляет п. 1.

                                                                        Ну и так далее — об этом можно написать отдельную статью.

                                                                        Справедливости ради необходимо отметить, что:
                                                                        1) все реальные проекты в области здравоохранения и социальной сферы отличаются высокой сложностью (сущность «пациент» гораздо сложнее сущности «гражданин», высокая противоречивая зарегулированность и т.п.)
                                                                        2) подобные проблемы есть не только у нас — пример с провалом ИТ-проекта Обамы известен всем; еще подобрана информация здесь www.cnews.ru/articles/2018-04-25_velikobritaniyasshaavstraliya_samye_epichnye_provaly_zarubezhnyh

                                                                        Only users with full accounts can post comments. Log in, please.