#1. Что такое проект?

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

Обсуждать мы будем IT-проект разработки какого-нибудь программного обеспечения. Веб-сайт это, мобильное приложение или что-то еще - не имеет значения.

Спойлер:

Все начинается с идеи. Идеи, это связи разных событий и наблюдений которые компонуются у нас в голове. Для бизнеса важна хорошая идея. Такая идея всегда сводится к нахождению неудовлетворенной потребности. Как же найти эту потребность и как сформулировать идею?

Кратчайший путь выглядит так: нужен 1 опытный программист (имеющий достаточно знаний чтобы бегло оценивать техническую возможность имплементации идеи), 1 IT-бизнес аналитик (человек, понимающий принципы разработки ПО а также потребности бизнеса. Он будет переводчиком с бизнес-языка на язык разработчика и обратно), и 1 специалист в любой сфере. Последний участник – назовем его Специалист - может быть кем угодно – врач, архитектор, художник, фотограф, предприниматель - не важно.  
Так у нас есть Аналитик, Разработчик и Специалист.

Грамотный аналитик попросит Специалиста рассказать о его бизнесе, в частности - описать все существующие процессы. Затем он задаст серию уточняющих вопросов и попытается выявить проблемные процессы в бизнесе Специалиста. Следующим шагом Аналитик попробует понять насколько эта проблема общая для бизнеса в этой сфере. Если проблема общая - Аналитик начнет подкидывать мысли, делать предположения и спрашивать у Специалиста "А сработало бы это, если бы мы сделали вот так?"

В какой-то момент у Аналитика будет достаточно черновых записей, чтобы поговорить с Разработчиком и понять, какую из проблем которые он "нащупал" в бизнесе Специалиста можно решить наиболее эффективно (деньги+время). К концу беседы у Разработчика будет примерное понимание того, что собирается стать проектом. У Специалиста будет понимание того, насколько ценен зарождающийся проект и к каким изменениям на рынке он может привести, а у Аналитика будет домашняя работа по проверке утверждений Специалиста, и собственных гипотез.

Короткий пример:

Специалист – владелец сети ресторанов.  
Поговорив с ним, Аналитик узнал, что в его бизнес сфере есть проблемы с доставкой - в пиковые часы доставщики на машинах застревают в пробках.  
Аналитик предложил разработать мобильное приложение для Специалиста, которое позволит студентам регистрироваться в приложении и помогать в доставке еды на велосипеде минуя всякие пробки.  
Разработчик оценил, что идея не сложная, т.к. в ресторане уже существует система регистрации заказов, а значит нужно будет лишь разработать мобильное приложение и добавить отображение телефонных заказов в общий пул откуда студенты смогут принимать заказы по принципу «кто быстрее» и доставлять за комиссионные.  
Немного поразмыслив, Аналитик предложил после разработки проекта предоставлять копию проекта другим ресторанам, по лицензии + процент с каждого заказа доставленного его приложением.

Итог: Специалист счастлив и уже предвкушает власть и доминирование. Разработчик думает над архитектурой приложения. Аналитик же едет домой проверять нет ли ничего похожего на рынке на данный момент. The end.

Встреча успешно закончилась. Блокнот с записями остался у Аналитика. Эти записи - и есть зарождающийся проект. Все, что было до этого – все обсуждения, глубокомысленные дискуссии и так далее – это были идеи. В тот момент когда эти идеи в виде какой-то структуры попали на черновую бумагу – это уже проект.

Схема – это графический документ, описывающий связи разных частей проекта. Схемы составляются для того, чтобы видеть общую картину (Birds-eye view) проекта. Единственное правило для схемы – она должна приносить пользу. Других правил нет, пока создатель схемы их сам не придумает. Если вы запилили схему и смотря на нее вам неясно какую конкретную пользу вам дает ее контент – значит что-то явно пошло не так ☺.

В схемах не желательно вписывать кучу текста, так как для этого составляются отдельные документы. Таким образом, в схеме мы оставляем только те элементы которые в определенном смысле можно назвать "задачами" либо "этапами", "стадиями". Придерживание подобной практики позволит держать схемы чистыми.

К примеру, вот часть схемы, которую я набросал в draw.io для проекта аппаратного шифровального устройства для мобильных телефонов.

Белым выделены шаги выполняемые ПО. Красным - вопросы которые нужно уточнить. Зеленым - те места где вопросов нет.

Итак, у нас была идея, которая стала проектом. Проект же мы визуализировали в рамках какой-то схемы/диаграммы чтобы понять наши дальнейшие шаги.

К сожалению, в обществе, часто, документами называют только те объекты, которые имеют какую-то юридическую ценность, тем самым, раздувая это понятие пропорционально своему эго.

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

По мере решения вопросов выведенных в изначальной схеме, результаты могут записываться в отдельные документы. Так, один документ может содержать описание результатов исследований, а в другом будет список необходимых вещей для решения какой-то задачи указанной на схеме.

Пример схемы, и сопутствующих ей документов:

Можно пойти еще дальше, и создать какое-то рабочее пространство в вебе, чтобы моментально делиться информацией с партнерами. Для этого отлично подойдет инструмент типа Trello:

На картинке выше - Канбан доска сделанная в Trello. В ней мы создали две колонки – General documentation и Upcoming meetings. В первой колонке задачи, которые мы вывели на схеме. Во второй – наш список встреч. После этого мы приглашаем "к доске" наших коллег и партнеров и вуаля – процесс кипит, работа идет, все сфокусированы и ничего не пропущено. Более подробно о Канбан досках мы поговорим через две статьи.

Итак, на данном этапе у нас есть идея, ставшая проектом. Есть схема с общим описанием планируемого рабочего процесса. Есть документы которые появились во время этого самого рабочего процесса и (опционально) есть рабочее веб-пространство где все участники проекта могут видеть текущий статус задач.

Важно подчеркнуть, что так же как и с документами и схемами, правил о создании досок, колонок и карточек нет, пока вы сами их не придумаете. Вы сами придаете смысл артефактам, которые создаете. К примеру в показанной выше Trello доске я использую красные лейблы для обозначения задач, которые еще не выполнены, и синие для тех – которые завершены (И еще я просто люблю цвета).

Следующий шаг:

Эскиз, это визуальная репрезентация сырой версии нашего проекта с общим описанием логики навигации и ключевых компонентов. Сейчас нарисую пример.

Вот:

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

Предположим эскиз принят и достигнуто согласие продолжать работать в указанном направлении. Следующий шаг - создание макета.

Макет (Mockup) – суть, тот же эскиз, однако с добавленными стилями, цветами и гораздо более презентабельным видом. Если для эскиза подойдет ручка и бумага, то для макета уже понадобится специальное ПО (напр. Figma, Adobe XD, Invision, и т.п.)

В итоге мы получаем такую красивую картинку:

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

Прототип (Prototype) – суть, совокупность макетов собранных воедино в рамках какого-то инструмента для создания интерактивности. Пример приложений позволяющих легко и быстро получить прототипы: Figma, InvisionApp, MarvelApp и множество других.

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

Следующий шаг после создания прототипа – это его валидация и утверждение уполномоченными лицами. Мы должны переделывать прототип столько раз, пока не придем к согласию с командой, что это то, что нужно (или пока нам не скажет клиент ☺).

После утверждения дизайна, мы переходим к следующему шагу:

В рамках этого мероприятия, главный разработчик, ответственный за проект описывает то, как должна функционировать система на всех ее уровнях. Дается описание того какие серверы и за что отвечают, какие API используются, как и какие данные передаются.  
Пример:

Детали по этой картинке мы пропускаем.

После того как архитектура проекта ясна, команда ознакамливается со сроками ориентировочными тратами, необходимыми для имплементации проекта. Если проект создавался для клиента - эта информация передается ему.

После согласования стоимости проекта, команда согласовывает ключевые даты в процессе разработки проекта, например:

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

В завершение статьи еще раз повторю одну мысль: Важным в проекте является только то, что приносит практическую пользу. Я видел десятки проектов в которых не было документации вообще. Я видел проекты которые переходили сразу на уровень прототипирования, минуя макеты и эскизы. Я даже знаю крупные компании которые сразу после эскиза переходят к разработке продукта. А что касается документа описывающего архитектуру проекта – то этот документ, не смотря на чрезвычайную важность, очень часто банально игнорируется. Обычно, чем меньше проект (по длительности разработки), тем меньше компания-разработчик следит за документацией и правильностью рабочего процесса.

Все что я написал здесь – это то, как делать вещи правильно. Однако это не догма, и при необходимости вы можете делать так, как считаете нужным, главное, чтобы вы не теряли фокус и знали свои следующие шаги.

Теперь мы знаем что такое IT-проект и из каких этапов он состоит.

В следующей статье мы обсудим то, какими понятиями оперируют проектные команды. В частности мы поговорим о том, что такое EPIC, User Story, Task, Sub-Task и Bug.