Но эти фразы…
Всякий раз, когда я слышу их, проекта либо нет (и это не самых худший сценарий), либо он с треском проваливался на различных стадиях внедрения.
Итак, 10 фраз или деструктивных желаний.
1. «Нам надо быстро, качественно и недорого»
Абсолютно нормальное желание! Тут все понятно, и комментарии излишни. Не может опытная команда работать за еду. Хотя, кто-то другой, очевидно, может.
Впрягаться в низкобюджетный проект, конечно, можно – кризис и прочее. Но нужно очень тщательно и осторожно прописывать все возможные ограничения и рамки. Все!
2. «Вы разверните систему, нам срочно надо, а с требованиями разберемся по ходу»
«У конкурентов же уже все внедрено, а мы опять в отстающих, надо срочно что-то делать».
Срочно нужна CRM-система – это не цель. Должны быть четкие, измеримые цели и задачи. Начать внедрение до того, как выявлены и сформулированы основные требования – заведомо обреченная инициатива.
3. «А давайте внедрим сразу всё»
Комплексный проект – мероприятие рисковое в наше время. Конечно, существуют примеры успешных комплексных внедрений, что называется «под ключ». Но это, пожалуй, в прошлом.
Скорость развития технологий, постоянно меняющиеся рынки и конкурентная «скороварка» неизбежно влекут постоянное изменение бизнес-процессов и моделей. Не впрягайтесь в долгую историю, завтра может все поменяться.
Расставляете приоритеты, начините с самого простого и важного, попробуйте использовать систему как сервис (кстати, про облака и CRM как сервис я еще напишу отдельную статью, уже почти накипело).
4. «Вот вам требования – идите делайте»
Можно долго и нудно писать про необходимость предпроектного обследования и последствия его отсутствия. Даже если у заказчика хорошо структурированы и описаны требования, но писали их не вы – риск ошибки значительный. Да что уж там, даже если писали вы – уточняйте, контролируйте, сверяйтесь. Уж лучше лишний Change Request, чем проваленный Краш-тест.
Знакомая всем картинка аргументирует без слов.
5. «А документооборот на CRM можно сделать? А процессинг? А проекты вести?»
Конечно, можно еще и пуговицы перламутровые пришить, «тут у кого какие способности. Вот у меня знакомый есть, за пол часа десятку так нарисует…».
xRM – новая парадигма, платформа для творчества, тут все понятно. И ответ — действительно МОЖНО. Опытный консультант и хороший .net-разработчик вам на этой платформе все что угодно сделает. Но сможете ли вы потом поддерживать и развивать этого монстра – большой вопрос.
Вы же не пылесосите утюгом, используйте технологии по назначению.
С другой стороны, многие вендоры сейчас пошли по пути развития многофункциональных бизнес-платформ, в которых CRM, финансы, операционная деятельность и многое другое представлено отдельными блоками. А если говорить об оn-line технологиях – то сервисами, как, например, в Dynamics 365. По мере необходимости вы просто в нужное время подключаете и отключаете те или иные функции. А платите только за то, что используете.
Но сейчас не об этом.
6. «Устав проекта нам не нужен. Зачем этот лишний формализм?»
Устав проекта – необходимая часть договора внедрения. Да, документ требует детальной проработки еще «на берегу». Да, уже на этапе его формирования, а это, разумеется, до подписания основного договора, необходимо подключить команду со стороны заказчика. Да, это затянет процедуру подписания, что не на руку недобросовестным внедренцам (поэтому они уставов и не пишут). Но без устава и адекватный план проекта невозможно построить. Хорошо написанный устав – это осмысленное руководство к действию и, если хотите, гарантия качества.
7. «ИТ-отдел и бизнес вовлекать во внедрение не будем, они так завалены текучкой. Пусть внешние консультанты придут и все сделают»
Тут я просто напишу, что ИТ и бизнес вовлекать нужно. Точка. Без них проекта не будет. Точка.
8. «Василий, ты такой молодец, а давай ты еще CRM-проектом будешь руководить?»
Очень важна роль руководителя проекта со стороны заказчика. Он обязательно должен обладать авторитетом и необходимыми полномочиями внутри компании, но это еще не все.
Руководить проектом это сложно и отнимает много времени, поэтому руководство проектом должно быть, если не единственной, то основной функцией сотрудника на время проекта.
9. «Нам не важен процесс, давайте вы сами»
«Ну вы же специалисты, да и задачи у нас типовые» и т.д. Ну что тут сказать, бывало и такое.
О важности активного участия заказчика во всех этапах проекта даже уже как-то не хочется говорить. Ибо, сколько ж… Обязательно договаривайтесь на старте о перечне и формате промежуточных контрольных участков (статусы, прототипы, тест-кейсы и т.п.). И об актуализации выходных документов, это сродни исходному коду. Помните про первую мысль про дешево и быстро.
10. «Нам не нужно обучение пользователей. Пусть читают мануал»
Теоретически, почему бы и нет. Но, на практике, мануалы часто пишутся еще до сдачи системы в эксплуатацию, поэтому не исключены несоответствия, которые, кстати, и устраняются на этапе обучения.
Плюс, на этом этапе очень часто от пользователей поступают ценные замечания и пожелания, а систему при этом еще не поздно поправить. Я уже не говорю о психологических аспектах и важности для пользователя чувствовать себя непосредственным участником происходящих в компании изменений, а не сторонним наблюдателем. В конце концов, пользователи – это главные критики и рецензенты, которым потом со всем этим жить и работать, поэтому важность обучения нельзя недооценивать.
Разумеется, это не все деструктивные идеи заказчиков, с которыми приходится или бороться, или мириться. В любом случае, лучше уже на старте выявить и оценить все возможные риски, и подумать – принимать их или отказаться сразу.
Успешных проектов!
Комментарии (37)
igorch96
15.03.2017 19:47+3«Лучше лишний ченж-реквест, чем проваленный креш-тест» — шикарная пословица… :)))
markusweb
15.03.2017 20:00+5А как же «Там все очень просто, смотрите...»?
interneto
16.03.2017 07:24Честно говоря с такими слогами в данное время очень часто сталкиваюсь. Зачастую заказчики не понимают, что в проектах бывают свои ньюансы и казалось бы простая задача может превратится в ад)
Le_Kotty
16.03.2017 10:55Точно, а если возразить сложно, то можно просто сесть и посмотреть)). Спасибо
Zonzen
15.03.2017 22:47-9Все 10 пунктов посвящены, как я понял, неопытным, начинающим исполнителям. Есть ГОСТ 34, есть техническое задание, есть рабочий проект, они подписаны заказчиком и исполнителем на каждой странице. Заказчик хочет шаг в сторону? Не вопрос. Делаем допсоглашение, вносим изменения в техзадание и рабпроект (за отдельные деньги), осмечиваем по новой проект, сдвигаем срок сдачи. Только так.
hp6812er
16.03.2017 07:24Заказчик хочет шаг в сторону? Не вопрос. Делаем допсоглашение, вносим изменения в техзадание и рабпроект (за отдельные деньги), осмечиваем по новой проект, сдвигаем срок сдачи. Только так.
И теряете немалую часть клиентов… Все, с кем за 10 лет работал гибко подходили к вопросу изменения ТЗ или рабочей документации. Ни разу за это никто не просил денег.
Analitik_Telecom
15.03.2017 23:20Скукота и очевидности. Здесь про ТЗ и CRM в разы круче писали.
Nick_Maverick
15.03.2017 23:42-1дык ссылки на примеры лучше. и желательно свои. а так да, живых, выпуклых примеров неплохо было б добавить. Пресейл, сейл и внедрение вообще полны анекдотами на эти десять тем причем пофиг что от crm до cad
Analitik_Telecom
15.03.2017 23:52Шикарное не мое, а вот и старое мое.
Le_Kotty
16.03.2017 11:05Соглашусь, что про ТЗ тут есть и круче, и спасибо за ссылку на шикарное — действительно круто!
К счастью, мой пост немного не про ТЗ. Тут скорее про проектные риски, выявляемые на стадии пресейла. Но если когда-нибудь буду писать про ТЗ (что вряд ли) — то обязательно сразу к Вам, за консультацией :).
Спасибо!
Subrisk
15.03.2017 23:47+3Ни примеров, ничего. Сразу видно — девушка не внедряла, а по большей части пиарила… Дайнемикс, не?))
Le_Kotty
16.03.2017 11:12-1Про примеры — ценная критика, учту. Только боюсь, каждый такой пример заслуживает, как минимум, отдельной статьи.
Внедряла примерно с пятОк платформ, а проекты сразу и не сосчитаю. И, конечно, после этого пиарила)).
Спасибо!
jvalter
16.03.2017 07:24Он обязательно должен обладать авторитетом и необходимыми полномочиями внутри компании
ируководство проектом должно быть, если не единственной, то основной функцией сотрудника на время проекта
так не бывает.
micgelly
16.03.2017 07:24+4Общепринятая ироничная поговорка про «быстро, качественно и недорого» придумана вполне определенными людьми желающими задрать цену. Во первых если трезво взглянуть на фразу отбросив эмоции, то все три желания вполне естественны. Это нормальные желания. Это ориентир, а не аксиома. Вы где нибудь видели человека в здравом уме произносящего фразу: «Хочу быстро, качественно и дорого»? Дорого не в смысле чтобы дорого выглядело, а дорого по затратам. Я лично таких не видел. Так что эту фразу лучше оставить в эпистолярном жанре в разделе юмор. А в реальности нормальный исполнитель выяснит у сначала у заказчика задачу. Затем поинтересуется в какой бюджет заказчик хочет уложиться и далее будет оценивать возможность выполнить поставленную задачу с учетом всех вводных. При этом объясняя всё заказчику. И ещё. Ценообразование это весьма непростая вещь. Реалии таковы, что дорого или дешево далеко не всегда не определяет качество. В качестве примера. Если заказать например изготовление печатных плат в России то будет долго и стоить будет как крыло от Боинга. А если заказать в Китае, то будет неприлично быстро и дешево. Так что…
И ещё. Вы весьма сумбурно и отрывисто, из абзацев по одному предложению, написали данную статью. И стилистика и подача фактов хромают на обе ноги. Читать не интересно. К сожалению это похоже скорее на выплескивание эмоций и явный сарказм по отношению к заказчику. В виде картинок. А если честно я бы не стал у вас заказывать проект потому, как вы даже здесь не смогли всё четко изложить. Так о каком качестве вашей работы может после этого идти речь?GrafDL
16.03.2017 09:12+1странно судить о профессионализме разработчиков компании по тому, как кто-то один сумбурно пишет статьи и не удосужился растянуть «топ 10 фраз» на три тома
Analitik_Telecom
16.03.2017 09:14Дык это не компания-разработчик, это компания-интегратор. Случай, когда трепло отросло, а внедряют чужое.
micgelly
16.03.2017 10:36Речь идет не о профессионализме написания художественных произведений типа «Война и Мир», а о доступности изложенного для понимания. Языковые способности служат для передачи информации между людьми и если хочешь быть понятым надо думать как и что говорить. Иначе на «топ 10 фраз» разработчика можно получить топ «10 фраз заказчика», а в итоге вместо десяти метровой башни можно получить десяти метровую яма.
Le_Kotty
16.03.2017 11:19-1Спасибо, коллега, за такой большой отзыв, и порченное на него время. Значит — не зря:).
Pakos
16.03.2017 10:20Ниже речь не об интеграторах.
Я лично таких не видел
«Быстро и качественно, затраты роли не играют» обычно нет(особенно сейчас, хотя раньше такие встречались, по крайней мере на словах), а вот «быстро и недорого, потом допилим» — сплошь и рядом. Так что все три, действительно, не получить. Претензии могут возникнуть разве что к варианту «Долго, качественно, недорого», т.к. первые два уже подразумевают значительные затраты.
то будет неприлично быстро и дешево
Быстро бы не сказал, при налаженных связях здесь сделать платы если и не дешевле, то быстрее (контактов не скажу — не я этим занимаюсь), учитывая необходимость доставки «оттуда» и наличие запаса комплектующих на складе, а неприлично дешёвые китайские комплектующие забыты как страшный сон. Если, конечно, подобное изготовление для вас не постоянный процесс производства, а разовые акции, то сделать разово там на тамошних деталях может быть и быстрее. при постоянном потоке всё равно где заказывать, при всплесках/спадах хотелось бы большей отзывчивости, а не лагов системы доставки.
eldarmusin
16.03.2017 08:52Я заметил что в IT редко используется clause by clause. А ведь именно он помогает понять ТЗ, разделить его на мелкие задачи, разделить среди специалистов.
При общении по радиосвязи с диспетчером, исполняющий должен всегда повторить указания другими словами, так как он понял. CbC как раз повторяет этот принцип.
Le_Kotty
16.03.2017 11:26Согласна. И сейчас уже не так уж редко используют, должна сказать. Хотя, методологии внедрения могут встречаться под разными названиями, но подход схожий.
adaptun
Недавно узнал, что на всеми любимой картинке с качелями есть игра слов на английском
Заказчик хотел «tire swing», а его услышали как «tier swing».
В русском переводе игра слов теряется.
А на оригинальной картинке остаётся.
Le_Kotty
Тоже не знала)). Спасибо большое!