Как подружить заказчика и исполнителя с помощью двух правильных букв?
Не буду ходить вокруг да около и томить в ожиданиях. Те самые две важные и полезные буквы, на которые возлагается огромная роль при взаимодействии «тех, кому надо сделать» и «тех, кто умеет делать, как надо» — это ТЗ. Вот только не надо закатывать глаза, всем своим видом демонстрируя свою «любовь» писать и составлять технические задания. Конечно, этот процесс трудоёмкий и порой отнимает, как нам кажется, слишком много времени. Тем более, почти никогда в жизни не бывает такого сценария, при котором заказчик всё подробно расписал, а подрядчик с первого раза всё правильно понял и сделал без единой правки или корректировки. Постоянно реальность в той или иной степени отличается от ожиданий.
Проблема, как мне кажется, заключается в том, что все прекрасно понимают, ЧТО такое ТЗ, но далеко не все умеют использовать его с максимальной эффективностью. Как результат, тратятся лишнее время, нервы и, самое главное, деньги. В связи с этим хочу поделиться своим опытом составления технических заданий и рассказать о пути, который привел меня к способности быстро и точно находить взаимопонимание с подрядчиками с помощью этих двух волшебных букв.
Однажды мне окончательно надоело постоянно тонуть в бесконечных обсуждениях и переписках, отнимающих непростительное количество рабочего времени. Тогда я начал задавать себе вопросы. Почему мои четкие указания могут понимать неправильно или искаженно? Как писать требования так, чтобы не появлялось лишних уточнений? В каком виде подрядчик может предоставлять промежуточные результаты, чтобы мы оба понимали, в том ли направлении двигаемся? Как, в конце концов, избавится от накапливающихся скриншотов, горы заметок в ежедневнике и «отмазок» в стиле «вы это написали в таком-то ответе на такое-то сообщение от такого-то числа»?
Руководствуясь правилом, что лечить надо не симптомы, а причину, я решил отложить конкретные рабочие инструменты в сторону и порыться в базовых настройках человеческой сути. Первое, что пришло в голову — это память.
Память у всех разная. Кто-то прекрасно помнит каждое слово, сказанное месяц назад, а кто-то забывает важные детали уже через минуту. Более того, в определенных обстоятельствах (устал, не выспался, забили голову разными задачами, переживания из-за личных проблем) даже обладатель феноменальной памяти может что-то забыть, не услышать, упустить.
Первый вывод напрашивается сам: Требуется единое место, которое всё будет помнить за нас во всех деталях.
Ещё один камень преткновения в общении между заказчиком и исполнителем кроется в восприятии. Например, если составляешь техническое задание для мобильного приложения, нельзя описывать кнопку авторизации такими словами, как «лаконичная, среднего размера, в пастельных тонах, читаемым шрифтом, немного ниже поля для пароля». Ведь не факт, что у твоего собеседника визуальное представление этой кнопки в точности совпадет с тем, что ты нарисовал в своей голове. В этом случае тебе придется точно расписывать оттенок цвета по пантону, размер в пикселях или в процентах относительно поля пароля, накидать варианты приемлемых шрифтов и в каких-нибудь единицах уточнить своё «немного ниже».
Можно, конечно, накидать подрядчику примеров из интернета с комментариями взять шрифт отсюда, а кнопку оттуда и т.п. Но намного проще и быстрее самому сделать что-то вроде наглядного прототипа. Причем, желательно, не только для отдельной кнопки, но и для всего проекта, чтобы сразу смотреть, как будет выглядеть готовое приложение в финальной сборке.
Но что делать, если я не дизайнер и специальным программам не обучен? Нанимать сотрудника, который это сделает? Значит, ещё и ему всё то же самое объяснять, и, между прочим, деньги платить? Могу и сам попробовать хоть в Paint, хоть Фотошопе, но это тоже время.
Вывод второй: Нужна возможность составления ТЗ с наглядной визуализацией, но не требующее глубоких навыков работы в графических редакторах.
Представим, что прототип интерфейса готов. Теперь для исполнителя необходимо донести информацию о том, как всё будет работать на практике. То есть, ТЗ должно включать в себя все возможные сценарии интерактивности будущего приложения. Это значит, что мне необходимо не только расписать алгоритмы отклика программы на те или иные действия пользователя, но и учесть различные условия (кнопка не активна, если заполнены не все поля; переход через «плюсик» к форме с нужным каталогом; возвращение в меню, в которое автоматически добавлена новая строка; ошибка при отсутствии позиции на остатках, изменение цвета кнопок; разные выплывающие списки подменю при выборе разных ролей и т.п.)
Благо, есть прекрасный инструмент моделирования бизнес-процессов с помощью нотаций BPMN, избавляющий от необходимости тратить много букв и слов, в которых ты и сам можешь запутаться. Что уж говорить про не погруженного в тему человека со стороны? Поэтому BPMN-диаграммы — это самое настоящее спасение, особенно для наглядной демонстрации сложных и многоуровневых схем. Кажется, если человеку, который до сих пор строчит безумные полотна текста или устраивает танцы с бубном в Word или Exel, показать BPMN, для него это станет таким же открытием, как переход от калькулятора к персональному компьютеру.
Конечно, диаграмма бизнес-процессов со всеми возможными сценариями — это отличное дополнение к техническому заданию. Но ещё более удобным и понятным было бы наделение интерактивностью и самого прототипа. А именно, сделать нарисованный интерфейс кликабельным, чтобы при нажатии на определенный элемент или кнопку, можно было перейти на соответствующую форму или раздел меню. То есть превратить прототип в своего рода рабочую демо-версию будущего приложения. Как вариант, чтобы исполнитель это сделал на основании предоставленной нотации BPMN, а мне останется только проверить и принять все заложенные алгоритмы и переходы.
Вывод №3: Минимизируем время описания сценариев работы будущего приложения за счёт готовых и давно популярных инструментов.
Что это мы всё про себя да про себя? Было бы для всех полезным оптимизировать и всё то, что касается обратной связи исполнителя. Да, он всё прекрасно понял, соорудил, нарисовал и оживил. Но нет предела совершенству, поэтому всегда по ходу разработки появятся новые ещё более гениальные идеи, обнаружатся неудобные или нелогичные места, или подрядчик проявил инициативу и предложил несколько отличных решений. В такие моменты можно снова прибегнуть к «любимому» текстовому описанию, что и где поправить, или делать скриншоты, обводя элементы, требующие внимания. И вновь здравствуй почта с чатом и старая добрая неуверенность в точности человеческого взаимопонимания.
Однако, решается данный вопрос быстро, легко и элегантно. Если мы вместе с исполнителем пользуемся одним сервисом прототипирования, который обладает функцией интерактивности, то логично привнести эту самую интерактивность и в диалог между сторонами. Просто выбираем любой нужный элемент интерфейса и пишем к нему персональный комментарий (заменить иконку, сделать по всей ширине экрана, поднять выше, перекрасить и т.п.) Ровно то же самое может делать и исполнитель, отвечая на мои комментарии или обращая внимание на свои правки и предложения. В последствии, когда одна из форм разработки будет согласована и принята, у меня, как заказчика, есть возможность её заблокировать в одностороннем порядке, чтобы никто случайно всё не испортил.
Вывод четвертый: Делаем обсуждение прототипа неотъемлемой частью прототипа.
А теперь должен признаться, что лихо и с энтузиазмом я забежал немного вперед и пропустил ещё одну часть любого технического задания. Коллеги, работающие в крупных организациях, меня поймут и, возможно, тяжело вздохнут. Речь о «воде» — той самой части ТЗ, состоящей из плана, вступления, целей, задач, позиционирования, описаний и прочего важного словесного наполнения, которое вместе со скриншотами прототипа и BPMN-диаграмм надо распечатать, подписать и приложить к договору.
Процесс такого сочинительства часто бывает одним из самых время затратных. И, даже, если вы являетесь тем человеком, для которого данный вид технической «литературы» — это призвание и любимое творческое занятие, то даже обычный набор текста на клавиатуре съедает драгоценные минуты и часы. Поэтому я отдал всю подобную рутину нейросетям. Я тоже считаю, что не совсем корректно называть «искусственный интеллект» интеллектом. Нет в GPT ничего подобного, по крайней мере, сейчас. Но, как шустрый обработчик больших массивов данных и инструмент для их дальнейшей генерации в готовый результат, ИИ вне конкуренции. Конечно, сочинить сюжет для драматической повести о корпоративных интригах я бы ему не доверил. Но с такими задачами, как составить подробный план ТЗ или написать 3000 знаков теоретической части, нейросети справляются буквально за считанные секунды. Обязательно приходится немного править и корректировать выданный результат, но в основном это касается только адаптации текста под индивидуальные особенности конкретного проекта. В любом случае, экономия времени в моём случае составила порядка 80%. А, если нет никакой существенной разницы, то зачем тратить больше?
Пятый вывод: Не брезговать нейросетями. Корректировать — намного быстрее, чем писать с нуля.
А теперь давайте соберем все пять выводов, которые мы успели сделать…, но сначала проверьте себя и свою память. Не листая статью обратно вверх, сможете вспомнить, какой тезис был выделен первым? А какой был вторым, третьим? На самом деле, результат не важен, но, если вы справились, то поздравляю. У вас либо всё прекрасно с памятью, либо вы конспектировали))
Итак, собираем наши пять путей к оптимизации ТЗ в единое целое:
1. Место, которое будет хранить всю информацию о проекте
2. Возможность делать наглядные ТЗ, не требующее особых навыков
3. Интерактивность и BPMN-схемы всех процессов и сценариев
4. Обсуждение проекта должно быть частью проекта
5. Нейросети в помощь для наполнения структурой и «водой»
Ну, а теперь, соблюдая правила драматургии, мне остается только взмахнуть волшебной палочкой и достать из шляпы… нет, не кролика, а ожидаемое решение, которое должно предоставлять возможность исполнить все указанные выше тезисы. И это мой старый друг, которым я когда-то пользовался только для одной единственной цели — создания прототипов форм и приложений, в основном на базе 1С. В своё время он назывался MAKER, но ключевое слово здесь «назывался».
В начале 2025 года сервис претерпел серьезные изменения. Во-первых, теперь это MAKER-STUDIO. А, во-вторых, это реально целая студия, которая больше не ограничивается одним лишь конструктором форм. И вот, как в нём всё компактно собирается.
— В инструментах прототипирования быстро из готовых элементов собираю нужную мне форму или набор форм, хоть для десктопа, хоть для мобилки, хоть для того и другого сразу. Недавно появилась новая панель с дизайном 1С: Элемент, который уже набирает особую популярность и востребованность. Не буду вдаваться в подробности изменения и редактирования отдельных элементов прототипа. Там всё интуитивно понятно и осваивается за первые 10 минут знакомства. Меняй цвет, размер, шрифт, иконки, наполнение… И не придется словами описывать, что, где и как должно располагаться. Всё уже видно более, чем наглядно.
— Сделал я несколько форм, которые по требуемому сценарию связываю с помощью кнопки… та-дам!!!… «СВЯЗАТЬ с ФОРМОЙ». И вот тут уже могу начинать пользоваться тумблером «Режим PLAY». Нетрудно догадаться, что в активном состоянии это и позволяет сделать прототип интерактивным. Нажимаю, допустим, на иконку «добавить» и выскакивает форма для «добавления», которую я заранее нарисовал и связал с соответствующей иконкой. Главное, не забыть добавить сценарий для связи и перехода в обратную сторону.
— На данном этапе уже можно всё отправлять разработчику при помощи функции «поделиться». На той стороне тоже пользуются MAKER-STUDIO, поэтому коллега откроет мою ссылку и увидит всё, что я сделал с прототипом. Но самое главное, что он может не только редактировать, но и оставлять комментарии к каждому отдельному элементу. И я на своей стороне тоже таким образом имею возможность точечно указывать на места для доработки или изменений и в дополнительном окошке пояснять подробности.
Подобное наглядное, точное и оперативное взаимодействие друг с другом сокращает не меньше половины временных затрат и снимает до 100% головной боли из-за того, что «тебя снова неправильно поняли».
— Далее, не выходя из сервиса, просто в отдельной вкладке при необходимости могу воспользоваться отдельным конструктором для построения BPMN-нотаций и детально прорисовать любую схему бизнес-процессов в форме диаграммы. Пользуюсь, кстати, не только, когда проект подразумевает сложные и насыщенные сценарии. Порой бывает полезно наглядно показать даже некий просто алгоритм в три-четыре действия, чтобы всё всем было ясно и понятно. Но самое главное, что инструмент BPMN-диаграмм — это не какой-то отдельный сервис, а часть одного проекта внутри одной программы, которым я точно так же могу «поделиться», просто поставив галочку.
— И снова, не выходя из сервиса, перехожу в раздел «Документации», где меня ждет полноценный текстовый редактор, который я буду использовать для создания подробного технического задания. Заголовки, списки, таблицы, картинки, ссылки на конкретные формы проекта — всё на месте. А, чтобы сократить самый большой кусок своего драгоценного времени, делегирую наполнение массивом текстовой «воды» нашему верному другу и помощнику — Искусственному интеллекту. Тем более, что таковой тоже имеется на борту программы. Есть один нюанс, на момент написания этой статьи MAKER-GPT работает в отдельной браузерной версии и в виде телеграмм-бота. Но разработчики уже анонсировали в ближайших релизах внедрить нейросеть в сервис, чтобы вообще никогда не сворачивать «окно» студии и делать всё, что требуется внутри. Из важных особенностей MAKER-GPT хотел бы выделить выбор определенных ролей и сохранение контекста. Да, так умеют делать и любые другие ИИ-ассистенты, но речь не о выборе GPT-помощника, а о том, что таковой присутствует в MAKER-STUDIO, как одна из полноценных функций. Грубо говоря, если бы я был механиком, лично мне удобнее, когда все нужные гаечные ключи, молотки, отвертки и прочие инструменты аккуратно лежали бы в одном удобном чемодане, чем таскать с собой пять разных сумок.
— Итак, в рамках проекта я имею готовые прототипы, BPMN-диаграммы и текстовое наполнение. Пришло время для последнего «фокуса». Ловким движением руки проект превращается… проект превращается… превращается проект… в элегантное готовое ТЗ. Двумя кликами я выгружаю все перечисленные выше элементы проекта в файл PDF или WORD. Алгоритм сервиса сам автоматически собирает все заготовки и верстает их в документ А4, который можно сразу пускать на печать или отправлять по почте. При этом, можно выгрузить готовое ТЗ как полностью, так и выборочно, проставляя галочки только на нужных мне формах, документах и схемах.
— Ну, и ещё один приятный штрих, который появился буквально на днях вместе с новым релизом MAKER-STUDIO — Канбан-доска, которая позволяет не только организовывать, делегировать и контролировать все описанные выше процессы, но и в дальнейшем руководить непосредственной реализацией проекта, все необходимые составляющие которого ловко умещаются в одном сервисе и в одном окне браузера.
Вместо заключения
Признаюсь честно, я пытался посчитать, сколько времени и сил я стал экономить, когда перешел на MAKER-STUDIO. Думаю, что не менее 50, а то и 70 процентов. Но затем понял, что мои подсчеты не будут отражать всю картину целиком, если я не учту, насколько быстрее и точнее стала работа подрядчика. Знаю точно, что каждый час консультаций, обсуждений и разработки я оплачиваю по тарифу. А, значит, я вынужден следовать формуле «время — деньги» в буквальном коммерческом смысле. Вы спросите, значит ли, что сокращение времени в половину привело к соответствующей экономии затрат? Не могу ответить однозначно. Ведь бюджет проекта складывается не только из одного лишь технического задания. Бывает по-разному. Иногда общие часы трудозатрат снижаются на четверть, а порой сразу в два или в три раза. Всё зависит от проекта. Но на 100% готов утверждать, что никогда раньше меня и моих партнеров так крепко не сплачивали две волшебные буквы ТЗ.
