Основные принципы командной работы

Аватар пользователя beer_destroyer beer_destroyer 28 августа 2007 в 23:25

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

Данная статья - попытка описать, как быстро и технологично можно работать в команде. Разумеется это не истина в последней инстанции. Разумеется будут возражения, и разумеется здесь не охвачено много частностей. Цель: показать, как можно довольно быстро выйти на промышленное производство сайтов с реальной оплатой за свой труд. В данном случае речь о команде установщиков друпала, но эти принципы применимы и для других объединений.
Для начала зададимся вопросом: а зачем вообще объединяться? Какие плюсы, минусы? Минус один: потеря самостоятельности. Но он компенсируется плюсами. Объединение начинает работать как коммерческая фирма. Доверие к таким объединениям тоже должно быть выше: не уедет завтра Пупкин в Израиль, и не займется торговлей алмазами, бросив свою клиентуру на произвол судьбы. То есть определенный % выделяется на пира акции, маркетинг, создается некая внутренняя структура, разделение труда...
Стоп. Зачем структура, зачем разделение? Мы можем делать все сами, работать как человек-оркестр. Дайте нам клиентуру и все.
Отвечаю: история учит, что при введении разделения труда в производстве английской булавки производительность возросла в 480(!) раз. Конвейер Генри Форда позволил серийно производить машины силами дешевых малоквалифицированных рабочих, создав в итоге автомобильную революцию в США. Теперь структура: всем понятно, что заказы бывают вкусненькие и не очень. Как делить бум? Кто делить будет? А почему тебе этот заказ, а не мне? А почему на Васе? Должен быть человек, который примет решение. Потому как объективных критериев нет. Назовем мы этого человека координатором.
В чем заключается его работа? Пиар, поиск клиентуры, первичная обработка, разная текучка, разруливание конфликтов... Ведение БД, но об этом ниже. Думаете конфликтов не будет? Хорошо, если так, а если будут? Бокс по переписке будем устраивать?
Следующая ступень менеджер проектов (МП) ака субподрядчик. Этот человек подписывает договора с заказчиками, утверждает ТЗ, выбивает деньги и пр. В том числе и предоставляет заказчику работу. Вообще с заказчиком общаться должен один, максимум 2 человека МП и дизайнер. Чтобы не играть в испорченный телефон. При этом дизайнер решает только вопросы его компетенции и под страхом изгнания из гильдии не касается других вопросов. Дизайнер: тут, вроде, все очевидно. Программист: и тут все понятно. Единственное: программировать надо по принятым в команде стандартам. За соблюдением которых строго следит координатор. Как это работает? А очень просто. Координатор, получив заказчика, назначает ему менеджера проекта. Тут определенную роль играет территориальное расположение, возможность встретиться и вообще рулетка, то есть случайность. Координатор должен быть беспристрастен и, как жена Цезаря, вне подозрений. Итак, МП получил заказчика (обратите внимание: заказчик и заказ вещи разные). Списался с ним и выяснил предварительно, что же тот хочет. Далее с этими предварительными желаниями он приходит на форум команды. "Ребята, есть человек, хочет то-то, сколько просить?". Или решает сам, на месте, из собственного опыта. В итоге получается цена вопроса. Если заказчика она не устраивает - разбегаемся или предлагаем более простые решения за его деньги... Но, предположим, все устраивает. Тогда следующий шаг: МП составляет ТЗ и присылает его заказчику для ознакомления. Заказчик дает устное добро. Следующий шаг: МП на закрытом (!) форуме предлагает работу членам команды: вот, ребят ТЗ, вот сроки, вот деньги: кто подпишется на дизайн, а кто на кодинг? Вызвалось ХХ человек. Отлично, значит будем выбирать. Как - увы, только субъективно, либо устроив аукцион "кто меньше". Остаток денег пойдет в общий банк команды, дабы не соблазнять МП... После этого можно подписывать договора, брать предоплату и начинать работу. Гладко было на бумаге...

Все мы люди, и что-то всегда может пойти не так. Но нельзя заваливать сроки. Что делать? Передавать работу другим людям из числа желающих. А вдруг горим, а никто не хочет сайт за день ваять? Тогда пробуем перенести сроки, или придется с общих денег увеличивать стоимость лота. Нельзя ронять репутацию фирмы. Вася сделал половину работы и запил... Или заболел. Вася получит хрен вместо денег. Или все же получит, сколько его сменщику позволит совесть. При условии передачи сделанной работы. А может получить и минус, если сроки лететь начинают... Увы, но и если заболел - все то же самое. Негуманно, но что делать-то? Либо сам перепоручай, либо как. МП, конечно, попробует сроки подвинуть, но тут как получится...Бочка меда и ложка дегтяВзявший любой лот (пусть это так называется) может его разбить на более маленькие части и перепоручить часть работы другим! Даже не обязательно из команды. Например это может быть написание модуля. Вот тут не надо забывать и про невкусное: отвечать за сроки и работу и т.п. будет перепоручивший. У МП есть "более другие" заботы. А как же субподрядчик? Может ли он все сам сделать и ни с кем не делиться? - А почему бы нет? Только это будет невыгодно ему в первую очередь. Да и всей команде. Я бы не стал, если заказов достаточно. Баблосы как делить бум?20-30% на развитие, рекламу, пиар и координатору. Надо будет мозговать и пересматривать, когда конвейер заработает. МП 20-25%. 10-20% дизайн и остальные 30-40 программеру. В зависимости от сложности дизайна и кодинга. Грубо говоря, и кодинг и дизайн вообще может оказаться нулевым. А почему так ма...А иначе как? Заказчика найти денег стоит, работа МП тоже стоит денег. Встреться, утверди, сдай, подпиши, реши проблемы... Часто будет получаться: кодинг 3 часа, а договор неделю и 7 поездок. Собственно, никто не мешает работать еще и на себя, делать целиком свои проекты. И даже никто не мешает ставить этим проектам высший приоритет, при условии выполнения командных обязательств. А как потом поддерживать чужой проект?

Очень просто. Сдавая работу сдаешь все. Если дизайн - то исходники и промежуточные, скажем, фотошопки, если кодинг: список чего, где, кто, когда и зачем менял. Все это заносится в БД и хранится в бекапах у координатора. А координатору не жирно ли...Не жирно. Кроме всего прочего он ведет базу по клиентам и решениям. Скажем, нет необходимости писать один и тот же модуль по 100 раз, можно взять готовый. Все это классифицирует координатор. Он же одобряет кодинг с точки зрения дальнейшей поддержки проекта. А как быть с иностранным рынком?Увы, тут я не слишком владею информацией, бо никогда там не работал. Мыслю так: на внешний рынок должен выходить один от имени команды. Можно представить себя как представителя фирилансеров, можно не пугать буржуев и прикинуться что сам все делать будешь. Можно выделить/нанять человека с очень хорошим английским/Макс пошел по этому пути/, который будет оперативно переводить. Хотя, не думаю, что языковый барьер такая сложная штука. А что дальше?

А дальше, господа, высказывайтесь. Хотелось бы увидеть людей, который согласны работать со мной как с МП в роле дизайнеров и кодировщиков, или того и другого в одном лице. Или же есть кто-то, кто хочет сам стать МП, и нанять на кодинг уже меня... Если таковые найдутся, думаю, будет иметь смысл прогнать несколько проектов по этой схеме, обкатать ее, и, надеюсь, перевести всю команду на эту технологию. Не согласны? Есть варианты лучше? Много/мало денег?Огласите. Я не Господь, и даже не Ленин. % - повод для обсуждения. Но не получится однозначно принять единые %, к сожадению. Бывает сложный дизайн и легкий кодинг, бывает все наоборот. Бывает заказчик сам все написал и называет цену, чуть ли не дизайн нарисовал, а бывает надо еще понять что ему надо, раз 10 встретиться, потерять кучу времени и заработать на метро и пиво, а то и в минус уйти, в итоге не получив заказа. Если заказчик крупный: предлагает один, утверждает другой, платит третий, а принимает четвертый. Не всегда они на месте. Полагаю, каждый сам так попадал. Поступило возражение: зачем еще одна бюрократическая структура? Исключительно затем, чтобы поставить на поток разработку сайтов. Был заявлен один из тезисов команды: "хотим по 50 баксов в час!" - и я хочу, и многие хотят. Абсолютно у каждого есть любимые и не очень любимые занятия, есть занятия где человек Профи, а есть где так себе, но вроде бы тоже надо делать... У автора нелюбимое - дизайн, а у кого-то кодинг, а кто-то любит кодить, но ненавидит писать модули... А кто-то великолепно торгуется и умеет/любит раскручивать заказчиков. Да даже если и не умеет: профессионализм приходит со временем. Представьте себе картину: человек сидит в тиши кабинета и творит. Занимается любимым делом, делает его хорошо и зарабатывает соответственно. Со временем набивает руку и на работу у него уходит все меньше и меньше времени. Соответственно растут и заработки. Разве это плохо? А вот мне в кайф все сделать одному! Бога ради! Но можно что-то одно делать прекрасно, чуть больше на хорошо, и еще чуть больше на посредственно. Если для вас удаленка - хобби, тогда конечно... Но если для вас это вопрос заработка - работать надо по промышленным схемам. Но эта схема работоспособна только когда есть достаточное количество заказов. Именно тогда возникает стимул к конвейерной работе. Вроде бы логично, что пока этого нет, и думать об этом рано. Но нет ничего более постоянного, чем временные решения. Пратический момент Наверняка это не всем придется по душе. Так и должно быть. Важно, чтобы согласились хотя бы несколько человек. Заработок выше индивидуалов минимум раз в 5 - самый сильный аргумент. вот тогда можно и на международный рынок выходить, и конкурировать там с таджиками от программирования - индусами. Которые, подозреваю, работают по аналогичной схеме.Очень хочется прочесть комментари присутствующих.Да, и сразу о (с) - http://cwll.biz. Ставим линк и копируем куда хочется... 

Комментарии

Аватар пользователя B.X B.X 29 августа 2007 в 0:28

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

Аватар пользователя sas@drupal.org sas@drupal.org 29 августа 2007 в 10:24

1) Принципы разделения труда и специализации +
2) Выделение координатора, МП -

это всегда "гордеев" узел и источник раздоров и дележа денег.
IMHO наличие формализации технологии при которой:
1) Сторонние используемые модули НЕ ИЗМЕНЯЮТСЯ; (При необходимости с использованием сторонних пишется свой в соответсвие с формализованной технологией команды и API);
2) Проект делится на функционально целостные подзадачи срок исполнения которых, позволяет проводит контроль сроков и качества
(члены команды составляют свои отдельные списки подзадач и скроков, в результате рождается неких общий вариант)
+ еще несколько пунктов
P.S. При определенном делении на этапы и подзадачи финансовая составляющая МП невелируется, МП без проблем при такой структуре может общаться с заказчиком торговаться, собирать подзадачи в единый проект (кстати это тоже подзадача, которая будет являтся частью проекта - свести субъективную составляющую оплаты работы в команде до минимума). Мысль простая состоит в том, чтобы не требовать каких-то маркетинговых денег за умение "втюхать" и "прорекламировать" заказчику работу - основная реклама - качество, уровень исполнения и авторитет команды, что как известно лучшая "живая" реклама, не требующая "навязчивой" активной деятельности, не говорящей о качестве исполнения.

3) Человеческий фактор, объективно всегда присутсвует ( болезни, форс-мажор и т.д.)
Использование градации сроков исполнения при форс-мажоре – нормальная практика работы с заказчиком, с учетом неустойки, то же относится к исполнителям команды, + еще несколько принципов ...

P.S.
1) Приоритет в команде - умения, знания, порядочность ее членов, что и создает общий качественный продукт людей принявших единую технологию программирования как результат общего обсуждения ее принципов.
2) Торговаться, продавать свои умения и общаться с заказчиком в той или иной степени здравомыслящие, умные люди и так умеют, не надо ставить это воглову углу, не беда даже если кто-то наотрез откажется от общения с заказчиком. Как показывает практика - сложное общение Заказчиком зачастую является инструментов "выкалачивания" дополнительных выгод последним основанным не на экономических принципах спроса - предложения а на «словоблудии» и блефе. И это не самые "интересные" Заказчики.

Аватар пользователя beer_destroyer beer_destroyer 29 августа 2007 в 17:35

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

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

Проблема дележа заработка решаема или на стадии объединения (твердый % на все и всем неисполнителям) или на стадии предложения МП ТЗ непосредственно исполнителям (это может провоцировать крысятничество).

Другие известные грабли: когда человек берется за дело, но либо не имеет квалификации, либо времени/желания. Обычно такие люди называются директорами, координаторами, чертом лысым, но в итоге видят себя исключительно рантье, собирающим бабло и попивающими пиво на Канарах.

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

Например в студии 100 чел, 20 проголосовали 11 за выборы => выборы.

Логичнее голосовать не челоек-голос, а доход - голос. Потому что человек, принесший 10 000 баксов важнее человека, принесшего 100 центов.

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

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

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

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