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

Итак, идея, витающая в воздухе, поймана в силки вашего сознания. Далее следует процесс конкретизации, составления бизнес-плана.

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

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

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

Техническое задание - еще одна бумага, которая в резной рамочке красного дерева должна украшать стены рабочих помещений руководящего звена, более того, для разработчиков стать своего рода Библией. За этим скромным заголовком таится панацея от всех проблем, связанных с процессом разработки, в случае, когда кто-то кого-то не понял, и, как следствие, не так сделал; ведущему разработчику упал кирпич на ногу/руку/голову, и фланг работ держать некому; ничего не делается в срок и никак не вычислить, кем именно не делается...

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

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

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

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

Для определения оптимального количества времени вполне подходит формула: время, реально требующееся на реализацию подзадачи, умножается на два, к полученному прибавляется еще 20-30%.

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

Все вышесказанное верно, если Заказчик является непосредственным начальником Исполнителя в рамках предприятия (один отдел ведет разработку для другого).

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

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

Количество рабочих рук, необходимое для качественной реализации проекта, один из самых интересных вопросов. Тем не менее, можно предположить, что каждый проект требует к себе внимания со стороны не менее трех профессионалов:

    дизайнера;
    программиста;
    вебмастера, компилирующего наработки дизайнера и программиста, а также являющегося консультантом по вопросам, связанным с Интернет, как для первого, так и для второго.

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

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

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

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

Почему необходимо учитывать специализацию? Потому что профессионал, какого бы высокого уровня он ни был, не всегда подходит для выполения конкретной задачи. Связано это с узкой специализацией, даже известно, что компании зачастую предпочитают обучение специалистов с нуля, нежели переквалификацию профессионала даже из, казалось бы, смежной области. Примеры из повседневной жизни: программист-разработчик интерфейсов и разработчик серверных приложений, использующие один и тот же язык программирования - C++; дизайнер, область приложения умений которого полиграфия, и веб-дизайнер, и так далее...

Поэтому поиск специалистов должен осуществляться непосредственно под конкретные проекты.

В настоящее время практикуются два варианта продажи самое себя для компаний-разработчиков: продажа отдельных сотрудников (для компаний, еще не обладающих весомым авторитетом; этот способ преобладает в России) и продажа команды целиком. Так что искать можно не только отдельных специалистов, но и команду, из них состоящую.

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

    Стресс-тест - максимально сжатые сроки, фактически "сделай хоть что-нибудь, только быстро". Сложность задания минимальна.
    Масс-тест - максимальная сложность задания, срок выполения - примерно 80% от оптимального количества времени, требующегося на выполнение задания. Проверка профессионального уровня.