оказалась слишком перегружена, поэтому решил написать здесь.
Помимо эпопеи с "Александром Васильевичем и его морскими котиками", было высказано несколько эмоциональных претензий к содержанию статьи (и статей Павлины вообще).
Сразу скажу, я дилетант в описываемой области. Поэтому стараюсь учиться на чужих ошибках (это всегда полезно). Цель данного сообщения — попытаться извлечь наиболее конструктивную критику статьи и обсудить ее с пользой для себя. Комментарии профессионалов — шароварных игроделов нам очень бы пригодились. Позвать кого-нибудь из swrus-games, что ли?
R>>"Имя, сестра!". Конкретнее — какие способы провальны, что предлагаете взамен? G>В замен предлагаю например брукса и его "человеко-месяц"
Есть возражения (на уровне ощущений). Думал, как бы это сформулировать... Ниже приеден результат этих усилий.
Статья Павлины, на мой взгляд, имеет множество полезных советов и практических рекомендаций. Но! Полезна она не всем IT-менеджерам (да Стив на это и не претендовал), а только тем людям, которые начинают бизнес в сфере разработки shareware-игр. Ниже приведу основные моменты, на которые, как мне кажется, нужно обратить внимание.
1. Sorry, Брукса начал читать недавно, еще не осилил, так что могу ошибаться в отношении его книги.
"Мифический человеко-месяц" описывает проекты в традиционной IT-индустрии. Здесь разработки ведутся достаточно длительное время, найти человека "с улицы" с необходимым набором навыков в предметной области очень сложно, и подготовка кадров имеет очень важное значение. Кроме того, при определенном уровне развития у компании появляются средства, которые можно вложить в длительные исследования (проекты, убыточные в течении большого отрезка времени, а, возможно, и вообще провальные). При этом можно закрывать глаза на отсутствие со стороны каких-то работников "полезного выхлопа" месяцами — если мы точно знаем, что эти люди будут полезны чуть позже (или в другом проекте).
Создание "больших" игр вполне вписывается в эти условия, и о нем в статье речи не идет.
2. Специфика, в которой вращается Павлина — это не совсем обычная IT-отрасль. Ее в российских условиях (с некоторой долей условности) можно сравнить с формированием команды для оффшорного программирования.
Почему? Как где-то уже писали, шароварная игра — это занятие, которым человек убивает время, пока ждет доставки заказанной пиццы. Жанр игрушки не особенно важен (аркада, 2d-экшн, настольные гонки, пасьянсы — что еще?). Способы реализации — как правило, их уйма, и есть готовые движки. Революцию в этой сфере никто никогда не провозглашает — пользователь просто уйдет от непонятной новинки к красивому клону очередного диггера.
Поэтому важен только результат (красивая отлаженная убивалка времени, которую легко скачать и оплатить, в которую сразу научишься играть и которая напомнит пару игрушек из детства) в строго отведенные временные рамки. Оборачиваемость — это все! У Вас нет толстосума-издателя с 6-значными бюджетами. Вы рискуете, по сути, всем. Каждая допущенная ошибка, может стать, по терминологии Синка
, фатальной. Прием в команду не того человека (и колебания по поводу расставания с ним) — одна из грубейших ошибок такого рода.
Создатель проекта вынужден играть по тем нотам, что есть под рукой. Павлина говорит: если нет 3D-дизайнера, но есть отличный 2D-художник — вцепитесь в него и создавайте 2D-игру! И это верно, черт возьми! Пока вы будете ждать дизайнера для своего гениального 3d-проекта, конкуренты (которых на этом рынке просто "кишелла кишмячная") продадут 5 игр. И получив бесценный опыт, сработанную команду и необходимые финансовые вливания, смогут уже совершать большие ошибки по примеру "больших" компаний.
Яркий пример — id Software. Начиная с шароварных проектов типа Captain Comic и Dangerous Dave, работая в жестких и ограниченных условиях, они заложили фундамент под будущие проекты, которые произвели фурор. Причем Quake 1 еще распространялся по принципу shareware.
Вот поэтому слаженная команда середнячков (подходящих друг к другу именно как кирпичики в мозаике) становится гораздо важнее, чем набор профессионалов, которые не смогут договориться. Об этом Павлина и говорит практически на протяжении всей статьи.
оказалась слишком перегружена, поэтому решил написать здесь.
Статью прочитал. Выскажусь по пунктам:
1 — Сначала команда, потом – проект.
На мой взгляд, тут речь идет о случае с небольшим размером инвестиций (и проекте с невысокой/непредсказуемой рентабельностью). Если компания производит профессиональное финансовое планирование и имеет достаточно средств, то они могу себе позволить длительное обучение сотрудника или оплату курсов, тренингов.
2 — Выбор правильных членов команды — единственно важный фактор успеха или провала проекта.
Очевидно – не единственный, но, безусловно, очень важный.
3 — Выбирайте командных игроков, не индивидуалов-суперзвезд.
Здесь видимо речь идет именно о секторе Shareware – игр.
А так, на мой взгляд, для разных задач этот критерий сильно различается.
4 — В команде должен быть единственный руководитель.
Безусловно! Он, конечно, может делегировать часть полномочий другим членам команды, но принцип единоначалия должен соблюдаться.
5 — Программа = команда
На мой взгляд, все-таки очень многое зависит от лидера.
6 — Поддерживайте связь
Да, да, да! Это уже классика.
7 — Разделяйте вознаграждение
О Да!!!
8 — Выгоняйте отстающих членов команды
см. пункт 1.
Подводя итоги, скажу свое мнение. Статья производит очень хорошее впечатление (хотя несколько вещей кажутся мне спорными), и действительно несет в себе много идей. А ее высокая ценность (и отличие от фундаментальных трудов в области управления персоналом) в том, что рассмотрена, конкретная, малоизученная область – Shareware.
Здравствуйте, retalik, Вы писали:
R>Вот поэтому слаженная команда середнячков (подходящих друг к другу именно как кирпичики в мозаике) становится гораздо важнее, чем набор профессионалов, которые не смогут договориться. Об этом Павлина и говорит практически на протяжении всей статьи.
Все так, но у такого подхода есть очень неприятная сторона: такая команда будет обречена на однотипные продукты — переход на другой качественный уровень всем составом команды будет невозможен ввиду ограниченых профессиональных качеств отдельных(всех?) членов. Для воплощения другой идеи, более качественной или просто другой направленности, нужно будет "обновить состав". Тут да, получаем подтверждение еще одной идеи Павлины — "программа=команда" или как-то так. Только посмотрите, пожалуйста, правде в глаза: сможете ли вы так часто находить новых кандидатов, сколько такой поиск займет времени, не проще ли и быстрее и дешевле будет научить более профессионального члена команды? А если не ограничиваться исключительно профессиональными качествами? А если заранее заложиться на то, что не все проекты будут удачными? Вобщем, мне кажется, тут слишком много "но", чтобы так просто смотреть на это дело.
WBR, Александр Мова
Re[2]: Работа в команде - 2
От:
Аноним
Дата:
27.02.04 18:54
Оценка:
Здравствуйте, Alex Mova, Вы писали:
AM>Все так, но у такого подхода есть очень неприятная сторона: такая команда будет обречена на однотипные продукты — переход на другой качественный уровень всем составом команды будет невозможен ввиду ограниченых профессиональных качеств отдельных(всех?) членов. Для воплощения другой идеи, более качественной или просто другой направленности, нужно будет "обновить состав". Тут да, получаем подтверждение еще одной идеи Павлины — "программа=команда" или как-то так. Только посмотрите, пожалуйста, правде в глаза: сможете ли вы так часто находить новых кандидатов, сколько такой поиск займет времени, не проще ли и быстрее и дешевле будет научить более профессионального члена команды? А если не ограничиваться исключительно профессиональными качествами? А если заранее заложиться на то, что не все проекты будут удачными? Вобщем, мне кажется, тут слишком много "но", чтобы так просто смотреть на это дело.
Тут много есть но, вопрос лишь один, с чего и как начинается какой-то проект. Есть финансовое обеспечение или нет, есть команда или надо её собрать, 1995 год или 2004. Я далеко не уверен, что многие шароварщики начинают проект с хорошим капиталом и готовой командой. Это уже не 1994 год, когда можно было с простым продуктом въехать на рынок одиночке. Мне показалось, что Павлина говорит про 1994-97 год, когда можно было просто собрать команду, заняться шароварой и заработать деньги. На рынке десятки предложений, не понравилось одно, найду другое. Нет сегодня- уж точно будет через месяц. А про то, что бы догнать конкурентов- я уже молчу.
Мне больше интересует другое. На текущей момент, что делать програмисту одиночке для продвижения своего продукта. Понятно, команды нет, финансов для содержания команды тоже нет. Если читать статью- пора ложить крест на задумке. Павлина явно этого момента не учитывает. А зря. Хотелось бы услышать его мнение по этому поводу. Поэтому статья выглядит немного криво. Ведь далеко не сама программа решает быть тебе на рынке или не быть.
Здравствуйте, Аноним, Вы писали:
А>Тут много есть но, вопрос лишь один, с чего и как начинается какой-то проект. Есть финансовое обеспечение или нет, есть команда или надо её собрать, 1995 год или 2004. Я далеко не уверен, что многие шароварщики начинают проект с хорошим капиталом и готовой командой.
Первый — нет, может и не второй и не пятый. И далеко не все дотягивают до успешного проекта, доход от которого позволит развиться. Есть статистика, девять из десяти созданых бизнесов терпят крах в течении первого года. Это справедливо и для шареваре.
А>Это уже не 1994 год, когда можно было с простым продуктом въехать на рынок одиночке. Мне показалось, что Павлина говорит про 1994-97 год, когда можно было просто собрать команду, заняться шароварой и заработать деньги. На рынке десятки предложений, не понравилось одно, найду другое. Нет сегодня- уж точно будет через месяц. А про то, что бы догнать конкурентов- я уже молчу.
Может быть он говорит так, потому что сказывается специфика игровой отрасли.
А>Мне больше интересует другое. На текущей момент, что делать програмисту одиночке для продвижения своего продукта. Понятно, команды нет, финансов для содержания команды тоже нет. Если читать статью- пора ложить крест на задумке. Павлина явно этого момента не учитывает. А зря. Хотелось бы услышать его мнение по этому поводу. Поэтому статья выглядит немного криво. Ведь далеко не сама программа решает быть тебе на рынке или не быть.
Минутку, а зачем тебе на данном этапе команда? Продукт же уже есть. Я понимаю, стоит набирать команду для создания продукта, но если есть продукт, то для продвижения команда не обязательна.
...
А>>Мне больше интересует другое. На текущей момент, что делать програмисту одиночке для продвижения своего продукта. Понятно, команды нет, финансов для содержания команды тоже нет. Если читать статью- пора ложить крест на задумке. Павлина явно этого момента не учитывает. А зря. Хотелось бы услышать его мнение по этому поводу. Поэтому статья выглядит немного криво. Ведь далеко не сама программа решает быть тебе на рынке или не быть. AM>Минутку, а зачем тебе на данном этапе команда? Продукт же уже есть. Я понимаю, стоит набирать команду для создания продукта, но если есть продукт, то для продвижения команда не обязательна.
Я не про себя говорю. На данный момент мне команда не нужна. Я говорю про тех, кто читает эту статью т хочет заняться шароварой (как я понимаю, статья для них написана). Поэтому и появились такие вопросы.
Здравствуйте, retalik, Вы писали:
R>Яркий пример — id Software. Начиная с шароварных проектов типа Captain Comic и Dangerous Dave, работая в жестких и ограниченных условиях, они заложили фундамент под будущие проекты, которые произвели фурор. Причем Quake 1 еще распространялся по принципу shareware.
Пример чего? Одна из немногих контор выпускавшая игры, и первая которая создала фёрст персон шутер.То-есть либо вы покупаете Wolfenstein либо на вашем компьютере чёрный экран дос....
Тоже самое можно сказать про ВестВуд (или Вирджин?) с Дюной 2 и последующей серией команд-и-конкверов....
Короче не надо сравнивать то время с настоящим, пустой рынок — готовый проглотить любой продукт и сейчас — когда про очередную гейму пишут : вышел новый клон (ИМЯ)...
Хотя оговорюсь, рынок был не пустой — он кишмя кишел аркадами типа
Captain Comic и Dangerous Dave
, для всяких там денди, спектрумов и их РС-версиями.
На счет командной работы мне нравиться вот эта статья. К сожалению никакого отношения к IT она не имеет, но с точки зрения командной работы для меня была интересна.
