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