>>Часть 1. До разработки. (там же расположена визуальная схема)
Визуальное отделение доработок элементов интерфейса
Мы придерживаемся такого правила: все изменения интерфейса в типовых или чужих объектах должны выделяться цветом. Мы выбрали нейтральный синий цвет. Идея не моя, я ее честно подсмотрел и взял на вооружение.
Выглядеть это может примерно вот так:
Выделяем заголовки, как на картинке, наименования колонок, кнопки и т.п. Может показаться мелочью, но когда на проекте работают разные команды, то при разборках или последующем сопровождении гораздо легче визуально сориентироваться, чья это работа. Любой вопрос пользователя с демонстрацией ситуации на программе значительно сокращает время консультантам. Они не разбираются типовой это функционал или нет. Если цвет синий, они сразу же эскалируют проблему дальше или автоматически смотрят документацию по объектам проекта.
Хоть это и не касается интерфейса, но обязательным стандартом является комментирование вносимых изменений в типовую конфигурацию. Кто, когда, в рамках какого технического задания сделал, что было, что стало и прочая информация. Этот момент подробно расписывать не вижу смысла.
Подсистемы
Практика, которую практически не встречается, когда берем объекты на сопровождение после других поставщика услуг по 1с.
Проект это или сопровождение, на любой логический блок всегда создаются подсистемы. Если это проект, то такую систему проще будет потом сопровождать. Если это сопровождение, то такие доработки так же проще сопровождать в последующем при расширении функционала или при доработках, пересекающихся с более ранними доработками.
В дальнейшем легко отбирать объекты, которые относятся к тем или иным доработкам.
Внутри подсистема имеет краткое описание.
Ограждаем пользователей клиента от разработчиков
Огромное количество раз я сталкивался с тем, что программисты 1с это далеко и не всегда люди, с которыми приятно общаться.
Во-первых, программисты 1с… это программисты со всеми вытекающими последствиями. Они могут быть неряшливы, иметь плохо поставленную речь. Они могут быть не обязательными, надменны с простыми пользователями. Все остальные в большинстве случаев являются исключением. Повторюсь, что я говорю про рядовых программистов и программистов 1с в частности. Если человек выбивается из этих характеристик, то это, скорее всего, исключение из правил.
Во-вторых, программисты ленивы. Если вы сталкивались в своей работе с фрилансерами, то понимаете, что это люди, которые спокойно могут сдавать сырой продукт. Их не волнует, что продукт не готов. Они сдают, что получилось, теперь тестируй и возвращай замечания. Они могут спокойно нарушать сроки сдачи и т.д. Мотивировать и стимулировать их достаточно трудно. Все эти трудности справедливы как для штатных специалистов, так и внутри франчей и у клиентов.
В-третьих, если ваш бизнес это услуги клиентам, которые используют программы 1с, то такой специалист легко уводим. Мало, что вы потеряете программиста, то вы рискуете потерять и клиента.
Все эти факторы склоняют нас к тому, чтобы создавать систему, в рамках которой влияние этих факторов можно значительно снизить.
Когда я только уволился из франча, в котором я начинал свой путь в 1с, я уже понимал, что основная проблема франча – текучка кадров. Специалисты уходили на клиентов или во фрилансеры. Отпочковывались в самостоятельные франчайзи. Франч, в котором я начинал работать, на тот момент существовал уже более 15 лет и этот вопрос никак не разрешался.
Я понимаю, что текучка неизбежна, но вот последствия этой текучки можно и нужно искоренять системно. Сама причина такого состояния во многих компаниях кроется в том, что специалиста соединяют напрямую с клиентом. Труд такого специалиста легко отчуждаем от компании-иполнителя, т.к. на специалисте замыкаются все основные процессы взаимодействия с клиентом. Собственно размыкание процессов взаимодействия и завязывание этих процессов на различные службы - это тот выход, который ведет из застоя в процветание и естественный рост.
Это очень медленный процесс, поэтому я заостряю внимание только на концепциях. Важно, чтобы между специалистом 1с и любым представителем клиента стоял человек. Это может быть бизнес-аналитик, аккаунт-менеджер, руководитель проектов и пр. Не важно, как вы назовете эту должность. Суть функции, которую необходимо выполнять – делать продукт деятельности специалиста 1с отчуждаемым. В дальнейшем человека, выполняющего такую функцию, я буду называть аккаунтом.
Для примера. Программисты 1с никогда не сдают свои работы напрямую клиенту. Они сдают работу сначала аккаунту, который очень придирчиво принимает работу, выявляет все нестыковки. Для программиста он имитирует клиента. И только после такого внутреннего тестирования, все вместе с документацией передается и сдается клиенту.
Что получается? Как происходит обычный процесс разработки? Клиент описывает потребности, программист выполняет, передает первый вариант клиенту, клиент смотрит, описывает замечания, дополнительные требования и возвращает на доработку. И так может происходить несколько раз. В конце концов, доработка принимается в работу.
У нас же это происходит за 1, максимум 2 итерации, где во вторую итерацию попадают очень незначительные штрихи. Хотя внутри нашей структуру происходят все те же самые итерации на внутреннем тестировании. Получается, что мы забрали у клиента его боль и решили эту проблему. Приходя в любую компанию после любых исполнителей по сопровождению, мы автоматически поднимаемся на такой уровень качества обслуживания, который не достижим ни внутренними сотрудниками компании, ни внешними подрядчиками, которые не используют внутреннее тестирование. Клиенты думают, что мы суперпрофессионалы, хотя на самом деле это заслуга системы, в которой могут работать очень посредственные специалисты.
Бонусом здесь является то, что специалист не может уйти просто так, разрушив отношения с клиентом, уводя клиента и т.д. У специалиста просто нет такой возможности. Пользователи клиента могут даже не знать, что у нас произошли какие-то изменения.
Аналогично дела обстоят и с консультантами. Их труд тоже можно отчуждать. Для этого есть видеоуроки, которые они делают. Мы избегаем живых консультаций. Все наши консультации либо удаленные, либо в виде видеоуроков, где разбираются конкретные проблемы пользователей. Это позволяет опять же работать посредственным консультантам на нашей стороне, но за счет сервиса, который предоставляется, этот фактор практически не играет никакой роли.
Промежуточные видеообзоры
Довольно часто бывает так, что требования клиента в процессе меняются. Меняются требования к внешнему виду, к логике действий пользователя, рождаются новые идеи.
Мы регулярно запрашиваем у разработчиков видеообзоры ихразработок. Такие 2-5 минутные ролики с объяснением того, как и куда нажимать, чтобы получить нужный результат. Такие видео делаются на базе сценариев тестирования, о которых я писал в прошлой части.
Мы не дожидаемся конца разработки, а сразу требуем накидать интерфейсную часть и еще не работоспособную первую модель отправляем в виде видео заказчику. Это не отнимает много времени, но позволяет нам упредить большие отклонения от ожиданий и наоборот, выявив эти ожидания, мы можем легко их превзойти.
Клиентам эта часть взаимодействия очень нравится, т.к. им не надо отрываться от своих обязанностей, чтобы открыть тестовую базу, зайти в нее, завести какие-то данные, чтобы посмотреть работает это или нет. Они просто смотрят и слушают короткое видео, делают выводы и дают обратную связь.
Написал по этому вопросу мало т.к. идея простая, но эта мелочь имеет непропорционально высокое значение в создании атмосферы «все включено» для клиента!
Делаем больше, чем ожидают
В процессе работы, вне зависимости на проекте вы или на сопровождении, необходимо всегда придерживаться этого правила. Сервис и качество услуг, при условии, что они избыточны, способны копить для исполнителя силу влияния. Эта сила копится гомеопатически. И если вы способны систематически предоставлять избыточный сервис, то вы автоматически получаете доступ к влиянию на клиента.
Через некоторое время, когда проект начнет запускаться в эксплуатацию, вам потребуются союзники на стороне клиента, которые будут лояльны к вам и на которых можно будет даже поддавить при необходимости. Вас будут разрывать между собственниками компании клиента, людьми подписывающими документы, рядовыми пользователями, которые могут много чего устроить в процессе приемки и т.п. Можно со всем этим справиться с помощью личностных способностей к лидерству, манипуляциям и пр. Можно собрать всех в кулак и двигать проект, затрачивая на это кучу собственных сил. А можно заранее накопить силу, которая поможет с легкостью вырулить из сложных ситуаций. Называю это силой, потому что это реально ощущается как уверенность на сложных переговорах.
Можно назвать это элементом CRM или еще как-то. По факту вы со всеми вокруг выстраиваете «дружеские» взаимоотношения, используя системный избыточный сервис. И строите эти отношения тоже системно.
Когда вы оказываете избыточный сервис, то кран потока этого сервиса в ваших руках. Вы, как драгдиллер, начинаете раздавать бесплатные дозы сервиса, формируя постоянных потребителей. Люди очень быстро привыкают к хорошему. И этот кран легко перекрыть. Вы никому не обязаны оказывать сервис сверх договоренностей.
У этого подхода есть один приятный бонус. Аппетиты клиентов всегда растут во время потребления. Очень часто бывает так, что делая какой-то бесплатный отчет или правила обмена или какую-то другую функцию, нас просили развить этот инструмент под вдруг появившиеся требования. В этом случае мы тут же совершаем продажу. Если первое было сделано по нашей доброй воле, в силу хорошего отношения к клиенту, то его требования это уже за отдельные деньги. Еще ни разу не встречал возражений при такой продаже. И никто не может ничего предъявить в плане того, что «дорого». Как правило, если потребность расширяется клиентом, то в оценку мы включаем и то, что было разработано бесплатно.
Важно понимать, что избыточный сервис должен быть системой, а не свойством конкретной личности. Это просто набор шагов. Если человек, который негативно относится к клиенту, выполнит дословно этот набор шагов, то у клиента должно создаться приятное впечатление, что он получил больше, чем ожидал. Это очень важный момент!
п.с. если вам интересна более детальная информация подобной тематики, то вы можете подписаться на рассылку тут