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