Почитал я, как люди бьются с пользователями своего софта и решил поделиться с миром опытом. Сразу скажу, что опыт у меня не маленький — в своё время мои программы пользовались большим спросом и на их поддержке я не одну собаку съел. В результате клиенты пИсали кипятком, а пользователи саботировали любой другой софт, спускаемый сверху, кроме моего. В качестве истории успеха приведу не слишком большой проект автоматизации АЗС. Был заказ от АЗС на разработку АРМ оператора. Задача была работать с бензоколонками, кассовым аппаратом, печатать отчёты для бухгалтерии и разного начальства и кое-какая внтуриконторная специфика.До меня у них был опыт внедрения заказного софта, но опыт был негативный — софт глючил, операторы его тихо ненавидели, большинство отчётов делалось на бумажке и калькуляторе, а кассовый аппарат воспринимался, как некий злой демон, которому нужно приносить поношения и вызвать техподдержку два раза в неделю. Заказчик разбирался в компьютерах на уровне очень и очень среднего пользователя, был запуган и порывался написать ТЗ, которое сводилось к описанию каких-то кнопочек на экране и шрифтам в отчётах при полном отсутствии требований к логике работы. Короче говоря, заказчик боялся, что ему сделают очередное говно и порывался погрязнуть в деталях в которых ничерта не соображал.
Этап первый – найти взаимопонимание с заказчиком.
Прежде всего, была проведена работа с заказчиком с целью достигнуть взаимопонимания и прекратить судорожные метания. Это была чистая политика и психология. Сначала я объяснил заказчику, что не собираюсь «доить» или «кидать» его. Что у меня есть некоторая репутация, и я ею весьма дорожу. Что репутация для меня дороже денег и, что я собираюсь либо выполнить работу хорошо, либо не буду за неё браться вообще. Я показал заказчику, что я профессионал, что мне можно верить. Также я ненавязчиво объяснил заказчику, что в некоторых вопросах я разбираюсь лучше него, и некоторые вещи я буду делать так, как я считаю нужным, но если я ошибусь, то я всё исправлю бесплатно, даже если придётся всё переделывать заново. Кроме того, я подвёл заказчика к мысли о том, что не нужно бросаться писать толмуды ТЗ, а имеет смысл сначала уточнить его потребности. Что, возможно, некоторые вещи будут значительно лучше, чем он рассчитывает, а некоторые ему совершенно не нужны и вместо них мы добавим действительно нужный функционал, но в любом случае, не стоит совершать необдуманных движений, и ТЗ мы будем делать вместе.Короче говоря:- Лично я считаю, что обязательно должен быть некий небольшой подготовительный ни к чему не обязывающий этап. Например для того, чтобы выработать тактику поведения или даже иметь возможность отказаться от проекта, если найдутся непреодолимые сложности.
- Правильно поставить себя с заказчиком и добиться его доверия. Это главное. Иногда видно, что лучше отказаться от работы, чем связываться с конфликтным заказчиком.
- Нужно определить, кто и что решает у заказчика, к кому обращаться по каким вопросам и т.п.
- Нужно чтобы, заказчик понял, что деньги не главное. Главное — чтобы он был счастлив. А деньги это плата за хорошую работу и его счастье. И что никто его не собирается обманывать.
- Договориться, о совместной разработке ТЗ. Причём, в данном случае, ТЗ пишу я, а заказчик излагает пожелания в свободной форме и в дальнейшем утверждает ТЗ. В любом случае ТЗ должно согласовываться. Если какие-то части ТЗ могут вызвать затруднения, то это нужно обязательно оговорить во избежание неприятных сюрпризов в дальнейшем.
- Заказчик понял, что с моей стороны будет некоторое давление; я не буду реализовывать некоторые откровенно бредовые пожелания, а некоторые вещи я будут делать так, как считаю нужным. В обмен заказчик получает своеобразную гарантию — если принятые мною решения окажутся не верными, то они однозначно будут исправлены.
- У меня будут некоторые дополнительные требования — возможность общаться с персоналом, который будет эксплуатировать программу, с бухгалтерией, возможность задавать много вопросов и возможность иметь доступ к объекту на время разработки и тестового периода. Короче говоря, мне нужно будет оказать некоторое содействие, но оно с лихвой окупится в дальнейшем.
Этап второй — логистика.
Ну, прежде всего, я попросил заказчика выразить свои самые смелые мечты. Что лично он хотел бы от софта. Причём заказчик несколько раз посылался «думать дальше» до тех пор, пока он не стал внятно рассказывать о своих желаниях и эти рассказы не стали повторяться. Несколько раз я подбрасывал ему идеи и указывал на недостатки некоторых предлагаемых им решений. В результате я убедился, что заказчик определился со своими основными желаниями. Затем я пошёл и несколько раз поговорил с персоналом. Выслушал их пожелания, высказал свои предложения. Посмотрел, как они работают сейчас. Посмотрел на нынешний софт. Поинтересовался, что не устраивает в текущем софте. Поговорил с бухгалтерией. Посмотрел отчёты. Спросил, чего в них не хватает. Затем со всем этим снова поговорил с заказчиком. Он узнал для себя много нового – оказывается, с точки зрения начальства рабочий процесс выглядит совсем не так, как со стороны непосредственных исполнителей.Итого:- Обязательно добиться того, чтобы заказчик определился с тем, чего он действительно хочет. Зачастую заказчик изначально приходит с мыслями «о зелёных кнопочках» и «фирменном логотипе на отчётах» и затрудняется сформулировать свои желания даже в общих чертах. Если не дать ему «созреть», то в результате может оказаться, что он хотел чего-то совсем другого или вообще ничего не хотел. Более того «созревший» заказчик, как правило, сильнее заинтересован в продукте и воспринимает его уже, как нечто реально существующее.
- Не нужно полностью отстранять заказчика от процесса творчества. Иногда я специально оставляю какой-то момент на потом на усмотрение заказчика, чтобы ему было над чем подумать и высказать своё веское мнение. Иногда это выливается в странные изменения уже почти готового продукта, но зато клиент счастлив.
- Обязательно нужно сложить личное мнение о техпроцессе и поговорить с людьми, которые будут непосредственно эксплуатировать систему. У них бывают очень странные пожелания, но в конечно счёте это сильно повышает производительность труда и качество системы.
- Согласовать мнение начальства (заказчика) и тех, кто будет эксплуатировать систему. Часто бывает конфликты интересов и если их не разрешить заранее, то можно нарваться на саботаж.
- Обязательно узнать, что нравится/не нравится в имеющемся софте. И что нравится/не нравится у конкурентов. Зачастую, именно это имеет решающее для заказчика значение и именно там кроются истинные причины, заставившие его пойти на разработку нового софта.
Этап третий – согласование ТЗ.
Наконец настал этап непосредственного написания и согласования ТЗ. Само ТЗ было изложено в достаточно вольном стиле с абсолютно минимальным набором технических терминов и максимальным упором на функционал — по поводу реализации лишь устанавливались общие рамки. Было несколько моментов, где наши с заказчиком мнения расходились кардинально. По некоторым из таких моментов мы договорились, что я сделаю так, как считаю нужным, а если окажусь не прав, то переделаю безвозмездно. По некоторым были намечены несколько возможных вариантов решения; окончательный вариант будет выбран позже. И по нескольким пунктам пришлось делать два варианта — заказчик упорно стоял на своём, но у меня уже был крайне положительный опыт и я был уверен, что победит мой вариант. Так и произошло — на этапе демонстрационной версии заказчику был продемонстрирован мои и его варианты и в двух из трёх случаев он выбрал мой вариант и радовался, как дитя.По этапам разбили проект на следующие этапы:- Согласование ТЗ (собственно, уже почти окончено).
- Я пишу технологический макет программы и испытываю его. Т.к. программа должна была работать с железом, то нужно было проверить некоторые решения на месте с доступом к живому железу.
- Я пишу макет программы, обладающий основным функционалом, показываю его заказчику и испытываю на железе и на персонале. По результатам мы окончательно определяемся с неясными пунктами ТЗ.
- Я отдаю первую пробную версию, и мы ставим её на тестовую эксплуатацию. Версия будет обладать основным функционалом, но некоторые вещи я буду дорабатывать и доделывать походу эксплуатации. Заодно принимаю пожелания в рамках ТЗ. Этот этап был фиксирован по максимальному сроку с целью, как защитить себя от лишних пожеланий заказчика, так и заказчика от вечных доделок.
- Я отдаю финальную версию, и внедряю её. В этот период я ещё принимаю некоторые пожелания. Тоже жёсткое ограничение по срокам. Заказчик платит остаток денег в течение этого периода в обмен на дистрибутив.
- Гарантийный период — я только исправляю ошибки, но не меняю функционал.
- Форма изложения ТЗ не столь важна, главное – оговорить основной функционал и спорные моменты. Более того спорные моменты это, собственно и есть то, из-за чего нужно делать ТЗ.
- Ещё раз спорные моменты и потенциальные сложности. Даже если их оговорить устно, то это в дальнейшем позволит быстро найти общий язык в случае непредвиденных проблем.
- Сроки нужно закладывать с запасом и указывать, какие именно изменения возможны на каждом этапе.
Всякого рода замечания, как сделать продукт популярным:
В самом проекте, я делал акцент на эргономичность и отказоустойчивость. Основное правило — с этой программой человек должен работать сутками не испытывая неудобства. Интерфейс должен быть вылизан идеально. Никаких ярких цветов, никакой лишней красоты. Никакого выпендрёжа. Никаких красивых шрифтов – Arial наш выбор. Люди с этой программой будут работать с утра до вечера годами. Автор сам должен поработать со своей программой до тех пор, пока его тошнить не начнёт. Нужно пялился в свой интерфейс сутками, и выполнять одни и те же действия сотни раз. И если что-то начинает нервировать, то править, невзирая на чины и регалии. Потом посадить за программу другого человека пусть с ней посидит и поработает. И если ему что-то неудобно, то править, не взирая ни на какие соображения здравого смысла. Не должно быть никаких отмазок, вроде «это задумывалось не так» или «это не укладывается в концепцию». Элементы управления могут дублироваться по пять раз, если они часто используются. Они могут находиться в самых неожиданных местах, если пользователь рассчитывает увидеть их именно там. Все шрифты должны быть такими, чтобы после суток упорного пяленья в монитор их всё ещё было видно. Даже если это не кошерно — столько шрифтов и их размеров, сколько нужно. И ещё раз — никаких ярких цветов. Смотреть до тех пор, пока не укачает. А когда укачает, править, чтобы не укачивало.Затем дать конечному пользователю, сесть рядом и просидеть пару рабочих дней. Если программа ориентирована на непрерывную активную работу, то посидеть неделю – посмотреть, как оно работает утром днём и вечером, как сменяются смены, как пользователи обучают друг-друга. Потом самому сеть и поработать за пользователя на его рабочем месте. Сразу станет видно, где нужно править. Если пользователь где-то остервенело щёлкает мышкой и по пять раз бросает мышь и хватается за клавиатуру, то править незамедлительно. В некоторых местах пришлось делать собственную экранную клавиатуру — это позволило не отвлекаться от экрана и не бросать мышь. В некоторых местах пришлось дублировать функции самым не тривиальным образом — пользователю казалось, что если «ткнуть вот в этот значок, то что-то должно произойти».Если пользователь может забыть нажать кнопку, а кнопка должна быть нажата, то кнопка должна нажиматься сама через указанное время или должно выскакивать напоминание. Если пользователь где-то часто опечатывается, то должна быть возможность исправить ситуацию. Если пользователь что-то пишет на бумажке при работе с программой, то нужно дать ему возможность делать заметки прямо в программе, даже если это десять раз глупо и не красиво. Если пользователь забывает, зачем нужна кнопка, то должна быть всплывающая подсказка, иконка и надпись. А ещё лучше — спросить, как оно, по его мнению, должно работать. Вот, когда всё всем нравится, то можно вылизать дизайн. Но потом ещё раз всё перепроверить на эргономичность.И чтобы ничего нельзя было испортить. Это принципиально. Пользователь никаким образом не должен иметь возможности что-то испортить. Бесполезно писать инструкции. Нужно десять раз всё перепроверять в программе, выводить предупреждения и диалоги и чтобы в каждом диалоге ответ по-умолчанию был выставлен в безопасное положение. Программа должна работать без обслуживания годами.Отчёты должны быть такими, чтобы любой дурак мог в них разобраться. Если нужно, то дублировать цифры и колонки в таблицах. Дублировать таблицы. Печатать пояснения и примечания, если выдаются странные результаты.Короче говоря, интерфейс в рабочем софте должен идти от пользователя, потом от тех процесса и только потом от мыслей и соображений автора и дизайна.Если пользователи будут кипятком писать от интерфейса программы, то они будут готовы на всё и у конкурентов не будет шансов, какой бы функционал и по какой цене они бы не предлагали.Если заказчик чувствует, что его мечты осуществляются, то он всегда будет готов пойти навстречу.Ещё одно замечание по поводу инструкций.
Как показывает жизненный опыт – развёрнутый хелп в программе практически бесполезен. Больше помогают простые доступные инструкции для каждой формы. Но даже этим никто и никогда не будет пользоваться.Нужно делать всплывающие подсказки и статусные строки. Нужно написать несколько инструкций для каждой категории пользователей для основных случаев. И обязательно распечатать. Положить/приклеить на рабочем месте. Желательно в виде «вопрос-ответ». И самым доступным и понятным языком. В эти манускрипты вносить все вопросы, которые на этапе внедрения задают больше одного-двух раз. Отдельно сделать инструкцию с тайным знанием для продвинутых пользователей. Пользователи будут молиться на эти бумажки.Начинать внедрение нужно с обучения одного-двух самых толковых пользователей. Дальше их нужно привлечь к процессу – как показывает опыт, пользователи значительно быстрее и легче обучают друг друга, чем поддаются обучению со стороны.Нужно обязательно подумать о тех, кто будет эту систему поддерживать. Для всякого рода администраторов нужно написать понятную инструкцию. Писать нужно в расчете, что читать будет человек, который разбирается в компьютерах, но которому абсолютно и категорически лениво во что-либо вникать. Этого человека пинками подняли со стула, возможно даже в выходной, и с формулировкой «программа работает не так как раньше» бросили на амбразуру. Нужно чтобы он быстро нашёл в инструкции свою проблему и пути её решения. Пусть решения будут не оптимальными, главное чтобы их можно было легко повторить без копания в потрохах программы. Оптимальный стиль изложения – небольшое введение в структуру системы, на случай если всё же придётся копаться в потрохах. Затем список возможных трудностей в виде «Если-то» и раздел с описанием некоторых редких служебных операций. Желательно, заранее наделать скриптов или программ для архивирования/разархивирования/восстановления и прочего администрирования. Саботаж со стороны тех.поддержки – это страшное дело. А, вот, если тех.поддержка на вашей стороне, то это сильно экономит нервы и время.Короче говоря, всё должно быть доступно и понятно и рассчитано на человека, который совершает некоторые простые повседневные действия не сильно вникая в тайный смысл происходящего. Всё должно быть продублировано в бумажном виде и иметься на местах. Пользователи отлично учат друг-друга. Тех.поддержка не должна ругать продукт, иначе она его угробит.В заключение хочу сказать, что с точки зрения исполнения подобный подход отлично себя зарекомендовал и был успешно опробован на нескольких крупных проектах. Сложности возникали с организацией работы, в некоторых случаях — выбиванием оплаты с заказчика и послегарантийной поддержкой, но это отдельная тема.Update:Небольшое Огромное дополнение по просьбам трудящихся.
Я специально не вдавался в детали проекта, так как текст и без того получился достаточно большой, да, и детали эти выходят за рамки обозначенной темы. Но тут в комментариях и инбоксе люди требуют подробностей. Чтобы соблюсти хоть какую-то связность и логичность текста я решил дописать небольшое дополнение и оформить его в виде ответа на комментарий пользователя «belnetmon» - надеюсь он не будет против.«Belnetmon: В посте описан по сути очередной «Опердень» как класс задач. Кстати, интересно, что продукт покрывал автоматизацией? какую область деятельности? Судя по тексту, описана итерационная разработка продукта по сути с нечеткими начальными требованиями. «Набросал каркас», «Не понравится — переделаю все бесплатно». В реальной жизни вообще такое очень редко бывает. Вторая особенность, которая сквозит — это то, что речь о заказной разработке для одного конкретного заказчика. Без какого-либо обобщения такой подход по опыту не тиражируем на других заказчиков, где отчет будет зависеть еще и от фазы луны. «Хочет — сделаем тут еще колонку». То есть получается даже на уровне тех же отчетов уникальность, которую при тиражировании на других заказчиков будет очень тяжело поддерживать.»
Это не «опердень» - это вполне успешный опыт фриланса. Насчёт того, что покрывал проект – стояла задача автоматизации АЗС. Как я упомянул в начале текста - управление бензоколонками, работа с кассовым аппаратом, выдача разнообразных отчётов. Логически - это работа с кассой (ведение кассы), продажа топлива с его спецификой, работа с картами оплаты (своими и банковскими), продажа сопутствующих товаров, учёт топлива, экспорт данных в бухгалтерию и т.п. На всё это накладывалась специфика торговли топливом – масса вариантов и способов оплаты, множество потенциальных нештатных ситуаций, рабочие смены, противоречивые требования нашего законодательства и т.п. Фактически, после внедрения программа единственным, с чем работали люди на заправке, и это накладывало очень жёсткие требования на эргономичность – оператор должен был 24 часа смотреть на экран и тысячи раз за день повторять одни и те же операции. Насчёт нечётких начальных требований. Ситуация была не совсем такая. Повторяю – на тот момент уже был большой опыт разработки и внедрения разнообразных систем автоматизации. Заказчик тоже имел большой опыт эксплуатации различных программ и оборудования, но мыслил шаблонами. Заказчик пришёл из-за того что всё имеющееся на рынке было либо не удобно, либо не обладало необходимым ему функционалом. В ходе работы с заказчиком ему были продемонстрированы новые подходы и возможности – в результате он понял, что есть возможность не просто сделать клон чужого продукта с небольшими изменениями, а новую полноценную систему. И мне кажется, что у многих читающих возникло некоторое недопонимание по поводу «Набросал каркас», «Не понравится — переделаю все бесплатно». Повторяю – заказчик мыслил стереотипами и шаблонами, сложившимися в результате эксплуатации неудачных систем. Если бы его всё устраивало, то он бы не обратился за разработкой нового продукта. Собственно вариантов было три. Первый - сразу сделать то, что просил заказчик и получить ещё один клон. Однако, я сильно не уверен, что клиент остался бы доволен. Скорее всего, на этапе внедрения он бы понял, что променял шило на мыло – получил то же, что у него было, но с некоторыми изменениями. Скорее всего, это оставило бы у него неприятный осадок и отбило желание сотрудничать дальше. И, уж, тем более, он не стал бы рекомендовать разработчика своим коллегам. Второй, вариант – давить на заказчика и с пеной у рта доказывать, какой я умный и какой он дурак. Надеюсь, все понимают, что это тупиковый путь – заказчик работает в этом бизнесе и раз он ещё не разорился, то он что-то в нём понимает. Поэтому был выбран третий путь – предложить заказчику «нулевой вариант» и взять ответственность на себя. Риск при этом был минимальный так как, повторюсь, уже был значительный положительный опыт работы в этой отрасли. Именно от сюда появились «набросал каркас», «Не понравится — переделаю все бесплатно». Убедить заказчика может только пример. Этот пример и есть «набросал каркас». А «переделаю всё бесплатно» - это гарантия для заказчика, что он не окажется жертвой амбиций разработчика. Если кто-то знает, какие ещё есть способы переубедить клиента - я с удовольствием их выслушаю, так как ни коим образом не претендую ни на абсолютную истину, ни даже на оригинальность. Теперь о «заказной разработке для одного конкретного заказчика». Прежде всего, это был фриланс. Если кому-то нужно типовая система, он покупает её у больших и жирных производителей, а не обращается к фрилансеру. К фрилансеру обращаются, когда нужен специфичный продукт. Так что это по-определению должна была быть «работа для одного конкретного заказчика». А во-вторых, у меня конечно же были заготовки, готовые модули и масса наработок от предыдущий проектов. А результаты описанного проекта неоднократно использовались в дальнейшем. Да, поддерживать уникальность потом бывает не просто. Но за это деньги платят. Альтернатива – вступать на путь прямой конкуренции с типовыми системами и крупными производителями, а это самоубийство для небольших разработчиков. Это всё равно, что с криком «Ура!» бросаться в одиночку с 1С конкурировать – никаких шансов. Короче говоря, фриланс держится на индивидуальной работе с заказчиком и уникальных предложениях. И ещё немного по технической части. Этот проект (как и большинство других) писался под Windows на Delphi. Так как этот язык позволяет разрабатывать интерактивные приложения при минимальных временных затратах. C++ - сложности с визуализацией, сложнее поддерживать проекты, сложнее отладка. .NET на тот момент была чем-то с непонятными перспективами (и время показало, что отказ от .NET был верным решением). Java же на тот момент была слишком медленной и «убогой». На данный момент я бы стал писать ту программу на Delphi или Java (в зависимости от требований заказчика). В качестве сервера баз данный применялся Firebird, так как он лучше всего обеспечивает поддержание целостности данных (при правильно описании структуры и правильно использовании транзакций). После примерно пяти лет непрерывной эксплуатации без обслуживания на офисном компьютере без ИБП (более того компьютер часто выключали просто отключая сетевой фильтр!) в базе данных не было найдено ни одного нарушения целостности. Честно говоря, даже на данный момент не представляю, какие ещё из бесплатных продуктов способны на такой подвиг.Небольшое дополнение: ищу работу — удалённую, обычную, частичную или на полную занятость, включая всякого рода стартапы. Огромный опыт в автоматизации всего и вся, в ведении и разработке проектов. Контроллеры, железо, автоматизация, АРМы и т.п.
