Проектирование → программирование
Мы, в IT-бюро, разработку системы управления делим на два этапа.

Проектирование включает в себя отрисовку всех страниц системы, описание алгоритма работы всего сайта и отдельных скриптов. Проект оформляем в виде ТЗ.

Любое наше ТЗ с внутренней перелинковкой. Разработчики могут быстро находить ответы на любые вопросы.

Примеры технических заданий:
Система учета бронирований чартерных рейсов
Система управления торговой компанией
Система управления транспортной компанией
Программный комплекс для гармонизации нейро-активности
Система прогнозирования рисков
ТЗ на разработку интернет-магазина обуви
ТЗ на разработку CRM-системы
Система управления зуботехнической лаборатории
ТЗ на разработку системы управления для медицинской ассоциации

Подготовка тех. задания происходит в режиме общения с заказчиком. Никаких брифов. Только плотное общение (скайп, демонстрация экрана). ТЗ готовит дизайнер. При разработке систем управления, чтобы спроектировать действительно удобный интерфейс дизайнеру нужно ощутить рабочий процесс живьем — выезжаем в любой регион.

При подготовке ТЗ всковыриваются все неровности задуманного проекта. Обыгрываются все сценарии, которые возможны: действия пользователя, администратора, распределение прав и т. д.. Итогом проектирование становится ТЗ с полностью описанной замкнутой системой. Замкнутой потому, что любой вариант развития событий описан в тех. задании.

Программирование. И только когда готово ТЗ — привлекаем разработчиков. Верстаем страницы по макетам и «склеиваем» их по описанным в ТЗ алгоритмам — программируем бекенд, тестируем и запускаем систему.

Если проанализировать историю человечества, главной движущей силой была и остается польза. Моисей организовал исход из Древнего Египта; Колумб поплыл пошел в Индию и случайно открыл Америку; Джобс разработал Макинтош — всё ради пользы.

Деньги полезны, но польза — это не деньги. Деньги это последствие полученной пользы. Мы помогаем достичь пользу, совершаем полезное действие. Вы приобретаете не набор механических действий, а билет в точку где необходимая польза у вас уже есть.

Мы можем многое, но не все. Прежде чем пообещать — изучаем задачу, считаем. Стоимость зависит от достижимости пользы, но стоит ли польза этих денег — решает клиент.

Польза и проект — не одно и тоже. Часто, чтобы реализовать проект нужно выполнить несколько итераций. Результат выполнения каждой итерации — пусть небольшая, но польза. Только так, иначе пропадает всякий смысл.

Flex по-английски — гнуть. Иногда бывает так, что лучше «подогнуть» проект, но сдать в срок и в рамках бюджета, чем продолжать жить без реализованного проекта. Если польза от запущенного проекта важнее некоторых неудобств, лучше флексить.

Николай Товеровский из Бюро Горбунова проделал большую работу — выделил и описал приёмы флекса (за что ему большое спасибо). Представляю «выжимку» из его работы со ссылками на статьи.


Виды флекса:

1. Зафиксировать

Часть системы делается статичной, её невозможно изменять или настраивать, поведение определяется заранее запрограммированным алгоритмом.
Подробнее

2. Снизить управляемость

Систему делают менее управляемой, но не жертвуют качеством и работоспособностью.
Подробнее

3. Уменьшить глубину проработки

Работа ведётся только над тем, что необходимо для решения задачи.
Подробнее

4. Рассогласовать

Изменяют только необходимую часть системы, игнорируя рассогласование с другими частями.
Подробнее

5. Убрать в гаражик

Неблаговидная часть системы прячется так, чтобы не портила вид.
Подробнее

6. Заменить решение

Если решение не подходит или его невозможно реализовать в срок, замените решение на другое.
Подробнее

7. Не выходить в надсистему

Решение не затрагивает других частей системы.
Подробнее

8. Отступить от идеала

Если реализовать идеальное решение невозможно или нерационально, отступите на шаг назад.
Подробнее

9. Перенести на следующую итерацию

Часть функций откладывают на потом.
Подробнее

Сделать говно

Сделать говно — это не пофлексить.
Подробнее

Флексить — больно. Если есть возможность обойтись без флекса — лучше её использовать. Если же поджимает время или ограничен бюджет, приходится флексить. Такова суровая реальность.

Лучше синица в руках, чем журавль в небе. Мы помним, что такой инструмент как флекс существует и умеем им пользоваться.

Обращаясь к пользователю со страниц сайта, мы обладаем ограниченным арсеналом инструментов. Сейчас можно использовать видео, аудиозаписи, изображения, анимацию, иконки. Но без текста не может обойтись практически ни одна страница.

Текст — важнейшая составляющая веб-дизайна. Часто этот компонент недооценивают, в том числе благодаря стереотипу «писать умеют все». На самом деле — все умеют сложить из букв услышанное или то, что хотели сказать. Но донести мысль, вложить её в голову, вызвать нужные эмоции, побудить на действия — могут далеко не все.

Написание текстов и редактура — наука и ремесло. Можно брынчать на гитаре по праздникам когда собираются гости, а можно играть профессионально и зарабатывать этим на жизнь. Никто не запрещает дурачиться на дружеской вечеринке, но на ответственное мероприятие лучше звать профессионалов.

Существуют разные стили языка, которыми пользуются исходя из функций текста. Есть разговорный стиль. Юристы пользуются официально-деловым. Диссертации пишут научным стилем, а романы — художественным. В интернете все сначала писали кому как вздумается. Но когда появилась возможность заработать с помощью сайта, стали думать — как писать, чтобы доверяли написанному.

Появился информационный стиль. Вообще, этот стиль существовал в журналистике и раньше, но обрел новый смысл. Методы и правила применения информационного стиля структурировал Максим Ильяхов, они изложены в книге «Пиши, сокращай».

Если коротко, тексты в информационном стиле не навязывают мнение и настроение. У них нет цели загипнотизировать пользователя или манипулировать им. Информационный стиль не ставит своей целью заискивать с посетителем, или развлечь его. Инфостиль объективно, точно и лаконично доносит информацию «как есть». Автор неформально и однозначно информирует пользователя и помогает принять взвешенное решение. Причем, взвешенное решение может быть «не покупать». Принимать решение — дело посетителя, решение зарождается внутри его головы, а не навязывается вычурным текстом.

Это сжатое представление об информационном стиле. Если бы я мог описать его принципы на одной странице — Максиму Ильяхову не пришлось бы много лет собирать материал и писать книгу. Если хотите углубиться в тему — изучите справочник Главреда или прочитайте упомянутую книгу.

Взглянем на примеры. Как инфостиль преображает текст.

Да, информационный стиль сокращает текст, если сравнить с текстом изобилующим пустыми, ничего не значащими словами. Инфостиль бьет сразу в цель, доносит суть, а выводы и оценки — делать пользователю. Мы, в маленьком бюро, уделяем тексту особое внимание — беспощадно вырезаем желчь и добавляем «мясо». Пишем текст для людей, который консультирует, вызывает доверие и продает.


Примеры статей в информационном стиле:
Хорошо ли продавцы в электричках хвалят свой товар Людмила Сарычева
Как устроен банкомат Сергей Король
Почему дисциплина лучше мотивации Андрей Банников

Текст в инфостиле на сайтах:
Энциклопедия услуг «Почты России»
Сайт дилера сотовых операторов
Агентство спортивного маркетинга

Ссылка по теме: Лекция Максима Ильяхова об информационном стиле

Картинки без программирования, как усилие воли без действия — ничто. Но, как без усилия воли не будет действия, так и без визуального представления проект не запрограммировать.

Программируем каталог товаров. «А какая структура каталога?» — спросит программист. Что ему ответить, если нет макета, если не представляем как будет выглядеть сайт? Вся логика продумывается на этапе проектирования дизайна, но не всё просматривается глядя на макеты. Что будет, если вместо квадратных иллюстраций (как нарисовано в макете) загрузить горизонтальные? «Как их выравнивать?„ — последует следующий вопрос программиста. Нельзя забывать о том, что дизайн не статичен. Реакция интерфейса на действия пользователя — это тоже дизайн.

Третий участник, больше всех заинтересованный в пуске проекта — клиент. Рассмотрим варианты взаимодействия и к чему они приводят на практике.

Дизайнер → Клиент ↔ Программисты

Дизайнер ↔ Клиент ↔ Программисты

Клиент ↔ Дизайнер ↔ Программисты

Продолжу аналогию, приведенную в начале поста. Если дизайнер это усилие воли, программист — действие, то клиент это мозг. Из мозга поступает сигнал, возникает усилие воли (намерение), в результате чего производится действие.


Мозг → Намерение → Действие

Мы, в маленьком бюро, запускаем проекты в тандеме с проверенными разработчиками. С клиентом разговариваем на понятном ему языке и не беспокоим по пустякам.

Иллюстрация макета веб-страницы: совет Артёма Горбунова о модульной сетке

Обманывать — плохо. Обманывать ожидания хуже вдвойне. Это неприятно как для обманутого, так и для обманувшего. Особенно если у обманувшего не было такого намерения.

Чтобы не обмануть ожидания клиента, чтобы клиент не потерял деньги и время за зря, а я не испытывал неловкость и муки совести — мы, в маленьком бюро, сначала убеждаемся, что поняли задачу.

Пример реальной заявки на разработку сайта:

Тут вроде как подойдет любое решение. Но если подходит любое решение — это не решение. Не понятно, зачем нужен сайт — для привлечения клиентов, которые будут покупать товар? Если так, то что за товар — ткани, услуги по пошиву, или готовые изделия? Может быть сайт нужен для того, чтобы фабрику находили поставщики тканей, и польза будет именно в этом.

Формулируйте задачу на языке бизнеса, не нужно её формулировать на языке дизайнера. Ведь сайт, система управления, мобильное приложение — это инструменты для решения задач в бизнесе. Но это не единственные инструменты и не всегда все работает так, как задумано. Чтобы привлечь внимание на выставке — девушка модельной внешности в костюме красной шапочки может сработать эффективнее, чем отличная статья и детально продуманная инфографика.

Прежде чем взяться за работу я дотошно стараюсь понять бизнес клиента. Задаю много вопросов и мы совместно приходим к формулировке задачи на языке бизнеса. Часто существует соблазн сформулировать задачу как «увеличить прибыль», но это следствие, нам нужна причина.

Повторю, причину (побудившую обратиться к дизайнеру) нужно сформулировать на языке бизнеса.

По итогам первых переговоров клиент получает документ «понимание задачи», который представляет из себя обычное электронное письмо. Документ не влечет никаких обязательств, но со старта дисциплинирует работу над проектом и позволяет клиенту убедиться в том, что дизайнер понял задачу. Одно дело кивать головой и поддакивать, совсем другое — письменно описать понятное. В тексте описывается не только задача на языке бизнеса, но и способ решить её (на языке дизайнера). Мы приходим у формуле:

Сделать то-то, сделав это

Вышесказанное можно проиллюстрировать проще. Мы приходим в парикмахерскую и объясняем причину, побудившую нас обратиться к парикмахеру (в чем дискомфорт сегодняшней прически, для каких целей нужна другая). Мастер входит в положение и советует как постричься. Если предложение устраивает — стрижемся.

Конечно, можно прийти к парикмахеру и обозначить параметры стрижки — длину локонов на каждом участке головы, угол скоса челки, интенсивность прореживания. Но опытный парикмахер не возьмется за такую задачу. Ведь если прическа не понравится виноват, все равно, будет парикмахер (хотя сделал как просили). Опытный парикмахер ценит клиента и своё душевное спокойствие. Смотрит глубже, устраняет дискомфорт и приближает к цели. Поэтому хорошие парикмахеры ценятся и к ним всегда возвращаются. Даже несмотря на то, что у них дороже.

Ссылка по теме: Лекция Ильи Бирмана о понимании задачи