Pull to refresh

Ошибки при внедрении Корпоративного портала или электронного документооборота

Reading time 11 min
Views 33K
Конечно подобный пост найдет голосовательное одобрение только в пламенных сердцах ИТ-подрядчиков, и бойцов прифронтовой кибернетической полосы — но думаю опубликовать будет не лишне!

Работаю АйТишником в крупной компании. В общем, все нормально и замечательно. Как-то однажды наше руководство решило идти в ногу со временем и возникли мысли автоматизироваться. Выбирали довольно долго Электронный документооборот, но либо денег жалко было много платить, либо разработчики какие-то липовые, короче, времени заняло все это переговорно-презентационное безобразие предостаточно. В конечном итоге остановились на некотором решении. Продукт адекватный, разработан под Microsoft Sharepoint 2013 Worklite Docs (я в силу некоторых обстоятельств с этой системой хорошо знаком). В общем выбор пал на него.

Мы собрали воедино все наши корпоративные хотелки, заказали, внедрили — запустили. Все нормально, все работает. Но суть не в этом. Это была присказка.

Намылился я в отпуск, ну и умотал как водится на пару недель майских, категорически забив на все и вся. Перед этим благополучно все перепроверив, сделав резервы, и посадив вместо себя помощника. А парень он — надо сказать малость туповатый, но крайне дотошный — притом к месту и не к месту. Строго настрого, запретил ему что либо трогать и щупать, и если что мне звонить (а я удаленно, как настоящий гуру, если что — подключусь и все сделаю).
Забыл сказать, что с их тех-поддержкой у меня установились некоторые дружеские отношения, поэтому мы друг к другу относились трепетно и нежно.

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

Как выяснилось парни разработчики оказались с юмором и замучившись с этим придурком — откатали ему письмо под названием «Памятка для клиента». Я ржал полдня. Потом малость его переработал и привожу здесь — несколько исправленный вариант, в художественном стиле. Теперь она у меня над рабочим местом висит в кабинете!

Привожу Содержание (опуская все регалии и обращения по корпоративному регламенту):

Типичные ошибки заказчиков при внедрении сложных систем на базе Sharepoint 2013:

1. «Мы сделаем сами»

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

Происходит примерно в следующем алгоритме (хронология событий может варьироваться):

1) Принимается решение о внедрении корпоративного портала и/или электронного документооборота

2) Выделяется бюджет в достаточно ограниченном объеме (заказчик ведь заранее лучше знает какой объем финансирования и сроков понадобится на проект, правда?)

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

4) После проведения 5-6 презентаций, формируется мнение «все это совсем не сложно, а наши Итшники уже отлично разбираются в вопросе». Но все таки здравый смысл обычно возобладает и принимается параллельное решение нанять хотя бы одного специалиста (желательно фриланса — тогда можно не платить зарплату)

5) Поднимается бодрый шквал рук со словами «это ерунда, сейчас вот посидим недельку, разберемся и кааааааак все сделаем сами». Притом наибольшее здравомыслие обычно как раз проявляет фриланс, смотрящий на все это действие по скайпу — с кислым сомнением, но вздохнув — естественно берется за работу (кто платит — тот и танцует).

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

7) С боем скомпоновав более менее удобоваримый план работ — наступает самая великолепная часть марлезонского балета — формирование Технического Задания. Это песня. Притом надо понимать, что просто план-набросок работ и подробное техническое задание с детализированным описанием каждого пункта — это вещи разные. Вот тут то и приходит первое озарение — оказывается оплата за разработку технического задания — это вовсе не такая уж и странная вещь. А написать ТЗ собственноручно, не имея в принципе никакого опыта — дело несколько трудоемкое… если не сказать больше — практически невозможное.

… Небольшое отступление от перечисления хронологии.

(все это время естественно платится зарплата всем участвующим лицам) Среднее количество одновременно занятых сотрудников — порядка трех, с минимальной зарплатой, допустим, в 50-70 тыс. руб. Все вышеперечисленное буйство духа — это примерно 2 месяца — значит 300 — 400 тыс руб. примерно уже впихнуто в проект, который по сути еще даже не начал путь к осуществлению. Итак продолжаем…

8) Итак. ТЗ написано. Бодрый, но бесконечно грустный фриланс начал свою кропотливую многомесячную работу. А мы пока перейдем к дизайну. Естественно для утверждения дизайна потребуется пройти весь вышеперечисленный путь (это само собой) — хотя в параллельном режиме. (некоторые Ответственные за проект предпочитают заниматься и дизайном и ТЗ одновременно, но обычно тогда проект вообще на этом заканчивает свое существование). То есть пока фриланс ваяет решение, ответственный за проект проходит все круги ада внутри компании еще раз, и становится закаленным в междепартаментных боях как Геркулес разрывающий пасть льву. В общем дизайн рано или поздно будет утвержден, поскольку художественная часть — наиболее простая, хотя и имеет конечно специфику в связке с Sharepoint. Кстати многие компании считают что дизайн не обязателен (поэтому унылый финал всей эпопеи — выглядит еще более уныло в свете стандартного майкрософтовского шаблона). Но это позже…

9) Далее бесконечно тянутся дни… тянутся и тянутся. Грустный фриланс становится еще грустнее, потому что выполнить в одиночку проект — довольно проблематично, да и специфичных направлений в ходе выполнения появляется довольно много, так же как и неучтенных правок, погрешностей, неточностей и т д. Итшники компании (про лес рук помните?) помогают как могут — но уже всплыло что очень много вещей требуют специальных навыков, опыта, и что вообще все не так весело как представлялось изначально. Соответственно сроки проекта затягиваются и затягиваются. Ответственный за проект естественно оказывается между молотом и наковальней и в общем то уже привык получать нагоняи от начальства и разбиваться о стену непонимания непокорного чужого фриланса и задорных, но бесконечно родных ИТшников. Как говорили классики «Розы на его щеках увяли и обратились в пепел».

10) В таком веселом безобразии проходят дни, недели, месяцы (иногда даже бывает годы)
Итог обычно печален. На выхлопе получается что странное, не очень удобное, кривое косое, с кучей статичных страниц и внешним видом псевдографики использовавшейся в середине 90 х годов. Но что самое забавное оно работает! Вываливается в ошибки, не позволяет сделать практически ничего (то ради чего все затевалось) — но работает. И даже используется!!! Ответственный за проект с видом варяжского крейсера — гордо поглядывает свысока на бледные тени подчиненных и позволяет даже поздороваться с собой за руку! Неважно что было затрачено средств (при тонких подсчетах) в четыре раза больше чем взяла бы компания-Разработчик, неважно даже что за сроки выполнения можно было бы завоевать небольшую африканскую страну и построить там небоскребы! Даже не важно что работать в этом совершенно невозможно, а открытие главной страницы — вызывает приступ панической депрессии абсолютно у всех, включая даже рыбок в аквариуме. Официально — проект выполнен! Ура!

P.S Через полгода, руководство приходит к мнению что в проекте все таки «что то не то» и после быстрых переговоров с 2-3 компаниями (учитывая грустный и выскооплачиваемый опыт) оперативно заключает договор с официальным разработчиком по смете.
Уважаемые клиенты! Разработка и внедрение своими силами сложных и специфичных решений На базе MS Sharepoint — это спорт людей отважных и с презрением относящихся к миру. Пробуйте, дерзайте, но на всякий случай сразу выделяйте двойной бюджет и готовьтесь к колоссальным срокам. Мы не несем ответственности за ваши ошибки как финансовые так и временные. И если даже на предыдущий фронт работ вами было уже потрачено (что бы своими силами что то сделать) несколько миллионов рублей и куча времени, это не значит что мы должны вам производить расчеты за свои работы по уменьшенной впятеро цене и обязуемся выполнить все за пару недель. Цените ваши деньги и наше время.

2. «Мы хотим дешево, много и сразу все… а лучше бесплатно»

Заказчик готов работать со сторонней компанией-исполнителем. У него есть уже оплаченное и сформированное сторонней компанией Техническое Задание и он прекрасно представляет что ему требуется, но оплачивать что то еще или не дай бог, заикаться о деньгах, категорически не хочет.

Часто бывает что заказчик уже представляет какой необходимый функционал ему требуется и ищет компанию исполнителя. ТЗ уже присутствует и в принципе разговор всегда довольно предметен во всех аспектах кроме финансирования. В большинстве случаев выясняется что клиенту необходимо практически все! То есть асболютно все что только может быть представлено на рынке технологий (Корпоративный Портал, СЭД, BI, KPI, Дизайн и т.д.), но бюджет настолько смехотворен что ни один разработчик всерьез не воспринимает его как потенциального клиента после оглашения максимально возможных финансовых затрат. Притом заказчик оттягивает огласку суммы бюджета буквально до последнего момента, всерьез расчитывая на то что такая политика может прокатить. Ну согласитесь — сумма, к примеру менее чем 500 тыс. руб, просто логически не может быть рассмотрена как бюджет на весь перечисленный функционал. Этот тип заказчика — обычно терроризирует — всех и вся. Бесконечные переписки, встречи, переговоры — что бы в конечном итоге выдавить из себя голосом сумму которая с трудом может покрыть Боржоми выпитое в процессе нервного расстройства у менеджера ведущего данного клиента.

Адекватные суммы (даже намного ниже рынка) — повергают его в ступор. Как золотая вдова в апельсиновыми глазами — заказчик оплывает на стуле, когда слышит сумму более 100 тыс. руб. и закатывает глаза с мыслью что его просто напросто решили ограбить.

Уважаемые клиенты! Пожалуйста, старайтесь адекватно понимать сложность и возможности финансовых затрат в разработках под MS Sharepoint. На данный момент в мире не существует решений или возможностей произвести серьезные разработки или осуществить внедрение подобных систем за подобные суммы. Нельзя внедрить или даже только запустить реализацию Системы Электронного Документооборота за 80 или 100 тысяч рублей — науке пока такие случаи неизвестны… Помните, что разработка «с нуля» под конкретную специфику заказчика — отличается от коробочного решения. И соразмерность финансовых затрат будет сильно полярной.

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

Мы не несем ответственности за резервирование, восстановление, обучение, эксперименты «а попробую ка я сделать вот так..» удаление, и неполадки — которые были осуществлены вашими специалистами в течение эксплуатации. Мы всегда готовы помочь заказчику, но не берем на себя ваши ошибки или обучение без должного финансирования и документального оформления.

3. «Мы купили у вас коробочное решение, теперь мы хотим что бы вы бесплатно обучили нашего специалиста — потому что мы не хотим платить за доработки в специфике нашей компании»

Заказчик бронирует и оплачивает коробочное решение. Ни о доработках, ни об обучении никаких разговоров или упоминаний не было. Ну а зачем платить, правильно? Ведь есть же свой системный администратор который обладает любыми навыками, начиная от построения системы интеллектуальной аналитики и заканчивая проектированием баллистических ракет. Он все сможет быстро и оперативно. Итак — руководство клиента оплачивает решение в базовом виде (без кастомизации и доработок) — заказчику поставляется и развертывается продукт на его мощностях, приходит грустный системный администратор или его помощник или помощник помощника (который все это удовольствие впервые видит) — и начинается игра в стиле «научите меня пожалуйста всему всему, я хочу уметь как вы! А если вы меня не научите — то вы плохие и я буду жаловаться..»

Уважаемые клиенты! Мы не несем ответственности за технические навыки ваших специалистов. Мы всегда рады предложить свои — но каждый труд, как вы понимаете, должен быть оплачен. Наши специалисты всегда будут счастливы — обучить, показать, доработать, переработать, разработать для вас все что угодно — но это потребует финансовых вложений с вашей стороны. Если вы купили машину, то автосалон не несет ответственности за ваше умение ей управлять. Если вы пожелали сэкономить на доработках решения под ваши нужды и посчитали что ваши специалисты справятся — то подразумевается что они обладают техническими специализациями данной отрасли и могут совершенно спокойно работать в таких приложения как Visual Studio и Sharepoint Designer — притом полностью понимая логику разработок под MS Sharepoint, а так же понимая логику движения процессов в СЭД, поручениях, ЭЦП, разработке вебчастей и т. д.

Техническая поддержка понимает под собой исключительно только консультативные работы в рамках реализованного функционала и не подразумевает обучение ваших специалистов. К сожалению мы не обладаем возможностями обучать бесплатно специалистов заказчика базовым навыкам работы с MS Sharepoint. Подобные курсы рекоммендуем проходить в специализированных учреждениях уровня «Специалист», или вносить в договор и оплачивать отдельно.

Примерно тот же самый вопрос хочется затронуть в случаях когда ваш специалист «убил» систему на своей стороне, все удалил, раздал админские права первым встречным или просто облил серверную стойку бензином и поджег: Мы занимаемся восстановлением, резервированием и структуризацией — только в случае если это явно указано в договоре и как следствие — было финансово обеспечено со стороны заказчика.

4. «Я ответственный за ведение проекта в нашей компании, но я очень хочу уехать неожиданно в отпуск или просто пропасть на пару недель — что бы ваши техники не могли со мной связаться по интересующим вопросам в рамках проекта, а потом хочу приехать и спросить — а почему не готово?»

При заключении договора на ведение фронта работ — мы первым делом обязательно настаиваем что бы со стороны заказчика было выделено ответственное лицо, которое будет отвечать за обратную связь со стороны клиента. Обычно это Руководитель ИТ или кто то из ближайших подчиненных. Хорошо если все гладко, но иногда бывает когда письмо от наших специалистов остается без ответа, а при детальном рассмотрении вопроса выясняется что Ответственный уехал в отпуск — погреть пятки на жарком Калифорнийском солнышке. В целом то неплохо, даже как то завидно. «Ах Америка — это страна, там гуляют и пьют без закуски». Только вот хотелось бы что бы предупреждали заранее или как то все таки скооперироваться в этом вопросе, поскольку — в процессе разработки — вопросов ох как много возникает. Потому что умотал — такой вот турист куда нибудь в страны дальние, и ни слова никому не сказал — отдувайтесь тут как хотите. А вернется — начальство его спросит «А как там, Петр Иванович, дела наши скорбные двигаются, например, по доработке карточки документа?». А Петр Иванович то и ни ухом ни рылом, отдыхал он, спонтанно так и плевать ему было и на карточку документа, и на сам документ, и на начальство, и на нас тоже заодно… Ну и как следствие давай е-мэйлы написывать нам, мол готово ли у вас все уже? Где посмотреть? И почему дескать, вы бездельничали, раздолбаи, за наши деньги?

Уважаемые клиенты! В процессе разработки — возникает огромное множество вопросов, и от вас требуется вербальное участие и оперативная обратная свзяь по вопросам связанным с двойственными моментами или просто с уточнениями, без ответов на которые продолжить логическую цепочку разработки крайне сложно, либо существует риск реализации не так и не того что необходимо именно вашей компании. Ответственный со стороны заказчика за проект — должен всегда находится в доступности по телефону, электронной почте или хотя бы скайпу. И огромная просьба уведомлять нас заранее об отсутствии. Если мы не можем добиться от вас ответа в течение недели — значит мы продлеваем сроки выполнения договора на эту неделю, и не стоит потом названивать каждые пять минут с вопросом 'А сейчас уже готово?". Извините, но мы потеряли из за вас неделю и поэтому мы не обязаны нести затраты на увеличение количества специалистов — что бы успеть в сроки, которые были сдвинуты по вашей вине.

С уважением, Техническая поддержка Worklite Docs.
Электронный документооборот и корпоративный портал Worklite
Tags:
Hubs:
+23
Comments 14
Comments Comments 14

Articles