keepsimple
dark
en | ru

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

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

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

Механика проект менеджера впервые получила свои общие очертания благодаря трудам господина Фредерика Уинслоуа Тейлора в далеком 1911м году. Его книга «Принципы научного менеджмента» впервые показала широкой общественности какие качественные изменения можно провести если использовать голову так, как и было задумано природой. Можете, кстати, прочесть эту книгу если вас интересуют истоки научного подхода к управленческой деятельности. Я так понял, ее не особо любят и не особо рекомендуют в нашем мега-обществе потому-что ее тон, говоря современным языком, неполиткорректен, и наверное он может обидеть чьи-то чувства. По факту же, книга – просто набор наблюдений Ф.Тейлора в которых показывается с какими проблелами сталкивался промышленный комплекс в его эпоху и какие именно проблемы привели к тому, чтобы научный подход (и здравый смысл) возобладал над тщеславной и слепой верой в свою правоту руководства тех времен.

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

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

Спойлер:

Идея.

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

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

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

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

Короткий пример: Специалист – владелец сети ресторанов. Аналитик узнал, что в их бизнесе есть проблемы с доставкой т.к. в пиковые часы машины-доставщики застревают в пробках. Аналитик предложил разработать мобильное приложение для Специалиста, которое позволит студентам регистрироваться в приложении и помогать в доставке еды на велосипеде минуя всякие пробки. Разработчик оценил, что идея не сложная, т.к. в ресторане уже существует система регистрации заказов, а значит нужно будет всего-то добавить перевод этих заказов в общий пул откуда студенты смогут принимать заказы по принципу «кто быстрее» и доставлять за комиссионные. Аналитик подумал еще дальше, и предложил после разработки проекта предоставлять клонированную версию (своего рода white label) другим ресторанам за процент с каждого чека. Специалист счастлив и уже предвкушает власть и доминирование. Разработчик уже думает над архитектурой приложения. Аналитик же едет домой проверять нет ли ничего похожего на рынке на данный момент. The end.

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

Схема.

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

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

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

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

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

Документация.

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

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

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

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

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

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

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

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

Эскиз (Wireframe).

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

Вот:

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

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

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

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

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

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

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

Approved UI Design

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

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

Software design – Или разработка архитектуры проекта.

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

Пример:

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

Cost calculation – оценка стоимости

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

Project planning – планирование проекта по срокам

После того как мы договорились по цене, мы договариваемся по срокам и записываем все в наш календарь в формате типа:

  • Jan 22, 2019 – Kick-off
  • Feb 18, 2019 – DEMO
  • March 8, 2019 - DEMO
  • April 9, 2019 - DEMO
  • May 25, 2019 - DEMO
  • June 30, 2019 – Project launch
  • August 15, 2019 – Stats review

Итак, контракт подписан, Jan 22, 2019 – Kick-off date, или, говоря простым языком, дата старта технической разработки проекта.

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

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

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

Теперь мы знаем что такое проект и из каких шагов он, в целом, состоит.

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