Жизнь повернулась очередной раз своей самой замечательной стороной, и я решил, что пора создать свой собственный «маленький свечной заводик». Проанализировав свой опыт управления проектами и последний опыт создания розничной сети, я решил, что самое простое и надежное – это интернет магазин, который торгует тем, на что есть гарантированный огромный спрос, и что в такой большое реке я всегда найду немного своей рыбки.
В результате был создан интернет магазин авто-мото шин и дисков MadRider. В процессе создания которого мне удалось побыть в роли заказчика ИТ проекта. И так перед нами чисто предпринимательская задача – нужно создать быстро и дешево очень хороший интернет магазин, который будет лучше конкурентов. При этом выбрать между быстро, дешево и качественно не получится, так как денег очень мало, сезон проходит и если затянуть, то до следующего сезона можно и не дотянуть, ну и так же с качеством. Он должен быть самый хороший.
Как я выбирал команду исполнителей, побывав в шкуре заказчика, а не исполнителя и представителя заказчика, как это было раньше, – достойно отдельной статьи. Частично ошибки продавцов ИТ услуг описаны в статье Выполним качественно и в срок. В рамках данной статьи упомяну лишь, что я разместил проект на free-lance.ru и выбрал исполнителя с самым подходящим опытом.
Изначально мною был составлен бриф. На полное ТЗ времени было жалко. Но учитывая весь свой опыт и понимание того, что торгуясь по цене при покупке проекта нужно понимать, что торг идет не в стоимости часа работ, а в количестве доработок.
Дешевле всех предлагают проект ни те, кто делал такие проекты много раз и четко понимают, сколько это занимает сил и времени, а те, кто попросту недооценил сложность работ.
Для того, чтобы исполнитель лучше понимал сложность работ, мы сделали бриф, согласовали его и финальную версию отправили друг другу письмом с указанием сроков и стоимости работ.
Запустив проект так торжественно и по всем правилам науки управления проектов, проект пошел по пути 99% других проектов. А именно начал тонуть в волне «доработок», «ошибок», «переносов сроков» и «изменении бюджетов». После трех месяцев работы (изначально был срок – 1 месяц) отношения были испорчены основательно, и стало понятно, что что-то идет не так. Исполнители жаловались, что как только они выставляют счет, то тут же начинаются к ним претензии. У меня было понимание, что мы очень далеко от запуска, и такое вот недоделанное чудо, где ничего толком не работает, запускать точно нельзя.
Опыт показался мне занятным, так как впервые в роли заказчика, проект простенький, всего-то интернет магазин, из специфики только подбор по типоразмерам шин. Опыт в ИТ есть, но чего не хватило?
Если вернуться к нашим ролям в ИТ проектах, и через эту призму посмотреть, то у нас были:
Заказчик, который не очень хорошо разбирается в функционале интернет магазинов, у которого постоянно нет времени на детализацию требований и на то, чтобы разобраться в базовом функционале, ну и куча новых идей каждый день.
Разработчик, который много и хорошо работает, который сам знает, как и что лучше сделать, и у которого нет ни времени ни желания уточнить у заказчика требования или вариант реализации.
Руководитель проекта, он же руководитель вэб студии. У которого основная задача была продать мне проект и после того, как проект был продан вся его роль свелась к пересылке моих требований разработчику и выклянчивания денег у меня.
Получается, была пропущена достаточно важная роль консультанта, который смог бы увязать все эти требования и пожелания, приоритезировать их и взаимоувязать. А самое главное – наложить на стандартный функционал движка интернет магазина и уберечь от ненужного программирования.
Ну, и была пропущена роль представителя заказчика, который бы, по сути, занимался администрированием проекта. И не дал бы пойти ему на самотек.
Но, а как же теория о том, что потребности не первичны, первичны возможности. У меня не было возможности содержать штат, который бы позволил выполнять все эти роли. А роли, так получаются, что обязательные. Маленькие проекты обречены на неудачу? Думаю, что нет, выполнение роли не зависит от размера проекта. Просто в маленьких проектах это можно делать проще ,и просто совмещать роли.
В моем конкретном случае нужно было кому-то, скорее всего, мне внимательно отнестись к роли консультанта, разобраться со стандартными функциями и давать более детальные задания разработчику. Ну и завести файл со списком требований, доработок и дополнительным расходам для базового администрирования проекта.
Получается, размер проекта не влияет на состав ролей по проекту, а может только увеличить требования к качеству выполнения каждой роли в проекте с увеличением рисков и масштабов проекта.
Ну, и роль руководителя проекта – «передаста» нужно или сокращать или комбинировать с консультантом, или продавцом.
