Последние 10 лет я отдал тому, что внедрял и запускал различной сложности проекты на 1С. Уже в самом начале моего пути в этой сфере я понял, что качество работы это одна из важнейших составляющих. Будучи наемным сотрудником, потом вольнонаемным, а позднее и в роли нанимателя, я все время совершенствовал свои методы работы с клиентами на проектах и в сопровождении. Оглядываясь вокруг, я вижу тотальное пренебрежение качеством работы, проекты «в стол» и дискредитацию сферы 1С. Это попытка борьбы с растущей энтропией в отрасли, продиктованной легким входом в сферу большого числа неофитов, а так же деятельностью различных компаний, которым только акты бы подписывать.
Это часть достаточно большой схемы, которую я использую для систематизации своего опыта. Сама схема родилась спонтанно. Однажды появилась потребность зафиксировать накопленный опыт, формализовать его. Часть этого процесса вылилась в оформленные регламенты для сотрудников. Другая часть процессов влилась в личную методику работы с клиентам и работает рефлекторно. На всякий случай продублировал схему в файлы, не уверен, что в отображении статьи не будет изображено превьюхой.
Я понимаю, что я не уникален и что многие в нашей сфере думают о клиенте больше, чем о разработке, деньгах или других аспектах. С удовольствием почерпну для себя что-то новое, если кто-то поделится.
Саму схему смотрите внизу.
П.С. это моя первая публикация, надеюсь, пинки будут не сильными ;)
Часть 1. До реализации
Фундамент качественной работы закладывается в самом начале работы с клиентом. Основным компонентом такой работы является тотальная прозрачность процесса. Вы можете встретить огромное количество людей, которые собственноручно напускают туман на свою деятельность. В сериале «Интерны» есть отличная серия, где Фил, жалуется Купитману на то, что его (Фила) пациенты не воспринимают всерьез, как врача. Купитман советует Филу создавать иллюзию значимости и загадочности, замалчивая, двусмысленно выражаясь и т.д. Естественно, пациенты, немного потерпев такой подход, через некоторое время начали отказываться от него, уходя к другим врачам.
типичный 1с-ник
Основная идея, которой я пользуюсь очень много лет, - это абсолютная прозрачность во всем. Все, что будет написано далее, это лишь нюансы, и различные проявления этой прозрачности в работе. Несмотря на простоту идеи, практическая реализация дается очень не легко и очень не дешево. Как у каждого хирурга-профессионала есть свое кладбище пациентов, так и у каждого профессионального внедренца есть кладбище заваленных клиентов. Они есть и у меня. Надеюсь материал будет кому-то полезен и позволит минимизировать потери со стороны тех, кто нас кормит. ;)
Модель взаимодействия
Важно с самого начала объяснить клиенту форматы работы, которые возможны при взаимодействии с вами. Очень часто в головах у людей есть только один путь реализации проекта. Они не знают его названия, но они видят, как строят дома. И этот способ лежит на бытовом уровне понимания, как строится все в этом мире. Это классическая водопадная модель (waterfall model), которая была описана Ройсом еще в 70е годы прошлого века. Мы с вами понимаем, что это не единственный и далеко не всегда самый оптимальный способ решения проблем клиента. И если это необходимо, то надо предложить альтернативные способы решения его проблемы. Научите его. Расскажите про итеративные подходы, про их плюсы и минусы.
Более подробно ознакомиться с самими подходами можно тут: http://www.rsdn.ru/article/Methodologies/SoftwareDevelopmentProcesses.xml
Или на просторах интернета.
Вы встретитесь со множеством возражений на этом этапе. Люди с трудом отдаются неопределенности. На первом евенте я познакомился с Александром Беловым и я был заворожен тем, как он легко отвечал на вопросы о неопределенных вещах, таких, как конечные сроки и конечная стоимость разработки. Не вдаваясь в технические нюансы такого подхода, это способ, который позволяет продавать предпроекты для водопадных проектов. Предпроекты продаются очень тяжело, многие компании идут на серьезное удешевление услуг на предпроектных работах, ради того, чтобы заполучить сам проект. Грамотное преподнесение, как минимум двух подходов – водопада и итераций, может как дать возможность хорошо отработать итеративно или как минимум так же хорошо продать предпроектные работы.
Здесь важна даже не сама модель разработки, а важен момент перекладки рисков за результаты проекта на клиента. Если вы видите, что итеративный подход для проекта очень хорошо подходит. Если вы видите, что бизнес заказчика склонен меняться, а он все равно настаивает на том, чтобы с самого начала были известны стоимость и сроки проекта. Смело уступайте, продавайте предпроект, но в протоколе встречи обязательно напишите, что представители заказчика уведомлены о различных вариантах реализации проекта и соответствующих рисках. Протоколы следует писать максимально детально. Это отнимает время сейчас, но экономит кучу нервов потом. Обязательно все протоколы подписываем. Часто случается, что уже после встречи, на холодную голову люди читают, понимают, что могут прогадать и возвращаются к разговорам об итерациях, просят более детально объяснить, что и как будет происходить.
Бонусами тут является то, что обучая клиента, вы так же создаете диалог с ним. Это позволяет выявить на ранних стадиях структуру принятия решений, на которую потом можно будет ориентироваться в различных ситуациях. Особенно это актуально для больших компаний, где далеко не сразу становится понятно, кто принимает решение и какими мотивами пользуются. У меня бывали ситуации, когда клиент категорически отрекшись от итеративного подхода со словами «в нашей компании это не возможно в ближайшие годы, будем работать по старинке», через месяц пересмотрел свое видение и вернулся к этому вопросу. Оказалось, что не он принимал решение, но т.к. протокол дошел до нужных людей, то эти люди подумали, взвесили, увидели здравое зерно и повторно инициировали переговоры на счет модели разработки.
Еще вы услышите еще на этой стадии, чего больше всего боится клиент, за что радеет. Выслушивая возражения клиента против какого-либо из подходов, вы узнаете причины этих возражений. Практически все возражения будут дублировать возражения, которые возникнут на этапе торгов. Это прекрасная возможность познакомиться с ними заранее. Тем более в такой отвлеченной форме, когда вы еще даже о деньгах не говорите.
Техническое задание
классика жанра
О технических заданиях уже много чего написано в других статьях, у Фарита есть курс по проектам, ГОСТы опять же. Мы все это используем, но всегда есть место для творчества.
Во-первых, мы склоняем клиентов к тому, чтобы ТЗ писалось не в стол. Мы избегаем воды и заранее предупреждаем, что наши формализованные мысли могут уложиться на несколько листов бумаги и они будут полностью отражать их требования и будут понятными всем. Мы старательно уходим от непонятных и никем не используемых томов на 300-500 листов, которые устаревают уже ко второму этапу проекта.
Во-вторых, мы достигаем понимаемости ТЗ клиентом. Мы пишем на языке пользователя. Например, если со стороны клиента есть ИТ-отдел, который будет курировать наш проект и человек понимает язык объектов конфигурации, то мы пишем ТЗ языком объектов конфигурации. Если же, перед нами бухгалтер, который видит только названия форм, кнопок и пр., то мы пишем ТЗ в его терминах, в терминах того, чем она пользуется. Это очень важный момент.
В-третьих, при формализации бизнес-процессов мы уходим от сложного описания. Практически любой бизнес-процесс можно разложить до линейных составляющих. Какие-то сложные циклы и ветвления бизнес-процесса, всегда можно укрупнить до более высокого уровня абстракции и расписать отдельно и детально каждый этап. Это позволяет внедрять управление процессами поэтапно, рассеивать риски внедрения всего проекта в целом. Мы стараемся придерживаться той нотации, которую предпочитает клиент. Здесь снова мы отталкиваемся от клиента.
Основное чего стоит добиваться, это чтобы ТЗ для клиента было понятно без пояснений. Если к вашему ТЗ нужны устные комментарии специалистов, то это плохое ТЗ, которое в дальнейшем имеет большие риски. Подписывая ТЗ, убеждайтесь, что клиент действительно понимает. Спрашивайте, понятно ли ему. Заверяйте, что если не понятно, то вы перепишете и достигнете понятного для всех формата описания.
Сценарий приемки
отказ от освидетельствования приравнивается к опьянению!
Этим принципом я бы рекомендовал пользоваться всем и везде. Отказ от формализации сценария тестирования должен приравниваться к сознательному саботажу на этапе сдачи-приемки работ.
Не смотря на кажущуюся необходимость, все почему то избегают формализации сценария тестирования. Но на самом деле это крайне необходимая вещь. Сценарий позволяет вам и клиенту комплексно взглянуть на то, что должно будет получиться в конце.
Даже куцый сценарий это всегда лучше, чем его отсутствие. В процессе сдачи вы столкнетесь с тем, что люди придумают способ, как завалить тестирование. Нажать не туда, не провести документ и смотреть потом отчеты и пр. Вам нужна последовательность действий, на которую вы будете ориентироваться при тестировании.
На небольших проектах или на задачах сопровождения сценарий обычно становится частью технического задания. В больших водопадных проектах это может быть отдельным этапом функционального моделирования с соответствующими документами на выходе.
Если заказчик упирается и избегает сценария тестирования, не хочет участвовать в его составлении, то это тревожный звонок. Мы обычно не двигаемся дальше, если этот этап не реализован. Если сделка из-за этого сворачивается, то это означает, что мы избежали очень больших проблем.
Управление изменениями
и вдруг заказчик захотел, чтобы все стали красненькими
Вы неизбежно столкнетесь с тем, что клиент что-то забыл сказать, по ходу проекта придумал новую идею. Это нормально. Но так же вы столкнетесь с тем, что бюджет проекта гораздо менее эластичен, чем требования заказчика.
Для того, чтобы обезопасить себя необходимо подписать соглашение об изменениях. Это может быть отдельный документ или быть частью договора, ТЗ. Конкретный вариант выбирается в зависимости от ситуации.
Вторая задача, которую решает этот документ, это опять же прозрачность. Вы еще на берегу с клиентом договариваетесь о том как будете работать. Что будет происходить, если вдруг они что-то забыли. Как будет обсчитываться сроки и стоимость. Мы всегда пишем, что в стоимость будет включаться расходы на все виды работ по возникающим изменениям, включая формализацию требований.
Дополнительная ценность
Если вы только начинаете работать в этой сфере, то этот пункт можно не выполнять. Но если вы в отрасли заказчика не первый раз или разбираетесь в предметной области, то необходимо это использовать.
Корректируйте, предлагайте другие варианты решения, оптимизируйте процессы и т.д. Как правило, это гораздо легче делать именно со стороны, т.к. у всех остальных участников уже давно глаз замылен. Люди могут не замечать совершенно простых вещей по разным причинам.
Но тут есть эмпирически обнаруженный нюанс. Создание ценности гораздо лучше воспринимается клиентом после выдержки некоторой паузы. Например, можно интервьюировать собеседника и в процессе вы вдруг видите возможность, которой они не пользуются. У вас есть два варианта: первый – тут же фонтанировать идеями и второй – взять таймаут. В первом варианте есть риски. Возможно, человек потратил много времени на задачу, не додумался или поленился. Вы не всегда знаете, кто перед вами. Далеко не всегда люди хотят видеть кого-то умнее себя.
Второй риск связан с тем, что вы размоете встречу. Т.е. вместо того, чтобы сконцентрироваться на потребностях клиента, вы начнете корректировать каждую идею клиента.
Я собрал на этом пути все возможные грабли. И мой рецепт таков: вы тихонько фиксируете все свои идеи на бумаге, молчите, выдерживаете паузу, а потом пишете письмо или делаете звонок. Где не навязчиво говорите о том, что вам что-то пришло в голову и это что-то может оказаться полезным и может сделать работу эффективнее, дешевле или принести какие-то другие полезности.
Даже если это не будет потом использоваться, то вы автоматически начинаете повышать свой статус в глазах клиента. Вы уже не просто исполнитель за деньги, вы думаете о клиенте, о том, чтобы ему было хорошо. И клиентам это нравится.
Но необходимо помнить, что самую благую идею можно испортить неправильным подходом.
Смета
Если вы подошли к этому этапу, то не стоит обольщаться. Иногда цену хотят знать сразу по телефону, это не означает, что люди готовы купить.
Здесь есть свой набор методик работы.
Важно придерживаться основного правила – прозрачность и понятность. В этом контексте смета должна быть максимально детализирована до логических элементов. Иногда люди просто пишут в коммерческих предложениях 1 млн. и все. За что? Что получит клиент в итоге? Это реальный пример наших конкурентов. Это реальный пример моих партнеров. Т.е. в голове у людей почему-то такая картина мира, где для клиента все это так же понятно, как и нам – специалистам. Это совсем не так.
Люди считают деньги. И для достижения прозрачности мы детализируем смету до элементарных составляющих. В нашем случае элементарная составляющая это логический элемент, который не всегда совпадает с объектом конфигурации, оценка которого не превышает 100 у.е. (для Москвы и Санкт-Петербурга - 250 у.е.)
Смета в этом случае получается довольно объемной, и требует времени на такую детализацию. У логических элементов бывают и исключения, например сложный отчет или сложная печатная форма, которая заранее превышает стоимость 100 у.е. эти элементы описываются с примечаниями.
Самые главные вопросы, на которые должна ответить смета: почему так дорого, это так сложно что-ли?
Детализируя до элементарных составляющих вы можете легко доказать, что это не сложно, вы все это делали, вы понимаете из чего будет состоять проект, вплоть до винтиков, но на все требуется время.
Т.е. одной из задач сметы является преодоление типовых возражений. Забудьте про свой уровень квалификации. Люди обращаются к суперспециалистам, только когда выбора нет. Если ваш рынок, это решение узкоспециализированных проблем, то вы можете бравировать этим. Это нормально. Во всех остальных случаях надо говорить, что это не сложно, это типовая для нас задача, мы понимаем весь процесс, но на все требуется время, это трудозатратно.
С таким подходом я не раз продавал проекты с ценой в три раза дороже по сравнению с оценкой конкурентов. Люди понимают, что дороже, но видят и могут сравнить подходы. При качественной работе с клиентами деньги становятся побочным эффектом.
Следующее, что необходимо помнить при оценке, это то, что до оценки нельзя допускать технических специалистов. Классическая ошибка, которую допускают 99% всех франчей – это работа технического специалиста или консультанта напрямую с клиентом. К этому вопросу мы еще вернемся на этапе разработки. Но здесь это тоже не маловажный фактор. Дело в том, что технический специалист по большому счету не заинтересован в проекте, как бы вы его не мотивировали. У денег слишком ограниченный ресурс воздействия на специалиста. У специалиста есть свои личные потребности, он может закладывать больше чем надо по деньгам и по срокам. Он может не понимать, что это имиджевый проект и деньги тут не главное. Он может не видеть всей картины в целом. Поэтому, да, необходимо получить сырую оценку от специалистов, но на эту оценку надо ориентироваться, но нельзя ей буквально следовать.
Опять же возвращаясь к А.Белову, мне понравился его подход к оценке сроков и стоимостей. Можно использовать и его, если сможете внедрить. Как альтернативу можно использовать экспертную оценку, т.е. оценку специалистом, который материально не заинтересован в растягивании сроков и стоимостей. Мы используем по большей части такой подход.
Детализация сметы до элементарных логических блоков здесь дает большое преимущество. Если в пункт «контур учета затрат» в смете можно зашить все что угодно и это будет тяжело оцениваемо, то детализируя до элементарных блоков, не нужно быть экспертом, чтобы спрогнозировать трудозатраты по каждому из блоков. Когда заказчики понимают за что именно они платят, они платят с гораздо большей уверенностью.
Очень часто можно встретить ситуацию, когда в оценку не входят этапы исследования, формализации требований. Это часто встречающаяся проблема. Чаще всего причина этого кроется в том, что вы не до конца обучили вашего клиента до этой оценки. Естественная реакция клиента будет такой: «я вам должен заплатить за то, чтобы вы поняли, как вам правильно выполнить свою работу?». Со стороны это выглядит действительно смешно. И мне часто задают этот вопрос и так же часто потом платят за исследовательскую часть. Здесь все просто с одной стороны и не просто с другой. С той стороны, где просто, необходимо иметь наглость и не бояться, понимая логически, что все фазы работы это труд и весь труд должен быть оплачен. С той стороны, где не просто, все зависит от того, на сколько конкурентно ваше потенциальное предложение. Если ваше предложение не отличается ничем от того, что может предложить рынок и оценка зашкаливает, вам придется подвинуться. Если вы только начинаете, то вам значительно дороже придется «покупать» ваших клиентов, чем если вы уже опытный игрок с отличным портфолио. Аналогично, если проект пилотный, то не надо драть втридорога.
Очень важно правильно защищать смету перед заказчиком. Опять же правильный подход автоматически выводит вас на правильную защиту. Мало продать проект, важно продать цену проекта. В отличии от тренингов по продажам, я скажу одно, если все делать правильно на предварительной работе до создания сметы, то ваша цена будет автоматически выше, чем в среднем по рынку. Связано это с тем, что чем глубже вы внедряетесь в проблемы заказчика, тем больше вы выясняете, тем больше первоначальные требования расширяются и тем больше становится стоимость проекта в целом. По моим наблюдениям наша цена, как правило, в 3-5 раз превышает аналогичные коммерческие предложения. Разница в том, что мои конкуренты не потрудились поработать с клиентом, прежде чем дать оценку, а дали ценник из своих представлений или из ТЗ, которое клиент разослал всем, чтобы собрать ценники. Мы же никогда не даем оценку на проекты удаленно, мы встречаемся, работаем и только потом называем цену. К моменту обозначения стоимостей, шансы, что проект будет нашим, очень высоки. Вопрос остается в цене. Детализированная смета позволяет легко парировать попытки сэкономить на элементарных блоках. Я просто предлагаю вычеркнуть, то, что заказчик считает нецелесообразным. Обычно логические блоки взаимосвязаны и мизерность стоимости элементарного блока (напомню, это максимум 100 у.е.) относительно стоимости всего проекта целиком делает такое вычеркивание бессмысленным.
Но здесь есть и другая сторона. У заказчика, возможно, действительно нет денег на все это удовольствие. Поэтому мы делаем из сметы три варианта: бюджет, стандарт и все включено. Элементарные блоки остаются теми же, но мы отказываемся от тех или иных контуров учета, сервисных возможностей и т.д. При этом стоимость на вариант «все включено» отличается от стандарта в 2-5 раз и на него действует специальное предложение.
Чем хорош такой вариант, он позволяет проекту начаться, а потом, зная о том, что есть более широкие возможности, заказчик сам докупает все необходимое. Или просто покупает «все включено» и вы сразу получаете крупный заказ.
При оценке так же важно закладывать риски. Обычно за кулисами мы считаем риски как +30% к срокам и стоимости от первоначальной оценки. Но эти риски надо куда-то деть. Детализированная смета не позволяет взять и придумать элементарные блоки с названием рисков. Это будет затруднительно продать. Но детализированная смета оперирует многими элементарными блоками, которые ниже максимальной стоимости блока, поэтому эти 30% размазываются на элементы нижнего ценового диапазона, добавляя по чуть-чуть к каждому элементу. Психологически это не вызывает дискомфорта, цена все равно низкой за каждый элемент. Дилемму этичности, которая может преследовать этот вопрос, мне так решить и не удалось. Если кто-то опишет свой подход к оценке и продаже рисков, буду очень признателен.
Как-то так.
[upd]: я задумал вести рассылку, если вам понравился материал, то можете подписаться на рассылку тут. Я и дальше буду публиковать материалы на ИС, в рассылку войдут материалы, которые не подходят ИС по формату, но которые жизненно необходимы нашему брату.
