«ПиЭмы» и аналитики очень нужны для определенных типов проектов. Например, в финансовой сфере предметная область очень сложна, и прямой контакт технарей с заказчиком будет весьма неэффективен именно из-за «языкового барьера». Аналитик тут выступает как посредник, который понимает достаточно с одной и с другой стороны, чтобы обеспечить нормальное общение.
Другой пример — разработка игр. Без project manager'a скоординировать работу сотни очень разномастных людей просто нереально. В этом случае он является каналом для общения с заказчиком — иначе будет полный хаос, и, опять-таки, конструктивного общения не получится.
Конечно, не со всеми заказчиками надо работать. И нарушать технологию по желанию заказчика тоже неправильно. Есть некие границы. Грубо говоря, в идеале заказчик говорит ЧТО СДЕЛАТЬ, а разработчик говорит КАК СДЕЛАТЬ. И, в идеале же, если заказчик начинает последовательно заползать на территорию разработчика, то работать с ним не надо (хотя, конечно, он вправе высказывать некие пожелания и давать некие советы).
Проблема в том, что заказчик зачастую не знает сам до конца, что именно он хочет, и совершенно не может внятно сформулировать это. Опытный разработчик постарается объяснить это заказчику. В рамках хлебной аллегории, я как заказчик хотел бы, чтобы разработчик не относился к моим требованиям формально, а сразу поинтересовался: «Хлеб ведь, наверное, в печке надо будет печь?»
И да, конечно, если заказчик категорически настаивает на том, что печка не побнадобится, то делать печку не нужно. Хотя, пожалуй, и из этого правила есть исключения.
Фраза «не надо с таким заказчиком работать» показывает, извините, ваш глубокий непрофессионализм. Дальнейший уровень ответа подтверждает это наблюдение.
Фраза «не надо с таким заказчиком работать» показывает, извините, ваш глубокий непрофессионализм. Дальнейший уровень ответа подтверждает это наблюдение.
Это — прекрасная иллюстрация того, чем ценен опыт работы вообще, и опыт работы в конкретной индустрии в частности. Разработчик с опытом работы в хлепопекарной индустрии с самого начала скажет себе: «Эге, господин заказчик, без печки да рецептов для разной выпечки никуда вам не деться, все равно понадобится», и заложит их в код сразу — без излишних деталей, но так, чтобы можно было без масштабных потрясений и переделок потом сделать все, как надо. Да и заказчику напомнит — а не забыл ли он про эти важные мелочи?
А еще надо сказать, что вот такой подход — сделать с точностью до буквы то, что сказали, и ни на йоту больше — заказчиков, как правило, сильно раздражает. И думается мне, что после очередной итерации закачик плюнет, да пойдет искать того, кто будет помогать ему, а не формально делать только то, что сказано.
Сказочка смешная, конечно, только вот в конце все на самом деле немного по-другому бывает.К тому моменту, когда менеджер приходит в шестой раз, класс у Маркуса достиг длины в три тысячи строк, из которых две с половиной приходятся на метод createBread, внутри которого находится замысловатая кострукция из семикратно вложенных if-ов. В этот момент Маркус обнаруживает, что, несмотря на все старания, он не может выполнить требование менеджера, поскольку от любого изменения его класс по мистическим причинам перестает работать. Так что далее Борис уже общается с менеджером в одиночку.
Тут вопрос такой: о каком применении идёт речь? Если о применении для оценки производительности программиста, то невозможно оценивать одни действия и не оценивать другие, результат будет бессмысленным и непредсказуемым. Ну, чтоб далеко за примером не ходить, я в прошлом месяце занимался разными изменениями в системах монетизации нашей игры, и коммерческий эффект был очевиден. А этот месяц я почти весь потратил на коренные изменения структур данных, которые (изменения) должны в будущем предотвратить серьёзные проблемы с базой данных. Но это в будущем, а пока эффекта — ноль целых ноль десятых.
Есть, однако, типы изменений, которые не дают очевидного на первый взгляд или легко измеримого коммерческого результата. Например, всевозможные системные работы, рефакторинги и т.п. Я сталкивался с ситуацией, когда начальство не давало делать подобные работы, именно мотивируя отсутствием видимой коммерческой пользы. Результат, увы, предсказуем :(
Вот был бы текст не столь поучителен и категоричен, и всё было бы нормально. Да, действительно, игру ЛУЧШЕ делать в команде. ЛУЧШЕ — но не обязательно. Просто работая в одиночку нужно трезво представлять себе свои возможности, и проектировать игру с их учетом. Приведенные выше контрпримеры как раз чудесно демонстрируют, как люди подстраивают проекты под возможности.
Далее. Там, где Вы говорите о продажах, правильнее было бы говорить о монетизации. Игру в наше время необязательно продавать — можно крутить рекламу, торговать виртуальными предметами, делать подписку… Есть масса вариантов.
Потом, Вы как-то смешали роли издателя и дистрибьютора, а это, в общем, разные роли.
Следующий вопрос — о раскрутке. Вы его вообще обошли стороной, а на самом деле это — один из очень болезненных вопросов для инди-разработчиков, и на него надо начать отвечать примерно одновременно с началом разработки.
Во-первых, электронное книгоиздательство делает необычайно острым вопрос о рекламе книги. Понятно, что «издать» в электронном виде книгу сейчас может любой желающий. А что дальше? Как хотя бы сообщить читателям (причем их большому количеству) о том, что появился новый шедевр? Это — очень непростая задача, требующая специфических знаний и денежных вложений. Большинству авторов она не под силу. Значит, нужны специальные конторы, которые этим будут заниматься, сиречь издательства. И им тоже надо платить. При этом, поскольку деньги им нужны до продаж, а рассчитывать на деньги автора им особого смысла нет, они будут вкладывать свои деньги, и при этом рисковать, поскольку предсказать заранее, что окупится, а что нет, нелегко. Соответственно, издательства будут строить отношения с писателями так, чтобы защититься на разных уровнях от возможного риска, то есть чтобы на удачном проекте вернуть то, что будет потеряно на нескольких неудачных. Так что «платить напрямую автору, а не праводержателю» не получается.
Ну и с «Платить надо за труд, а не за имя» тоже не все гладко. Имя уменьшает затраты на рекламу и риск. Понятно, что с «именем» работать гораздо легче, получить его выгодно, это хотят многие — ну, а следовательно, и цена растет. Закон рынка.
Обратная связь — дело, конечно, хорошее и нужное. Но прежде всего у рядовых сотрудников должна быть четкая уверенность, что их критика не приведет к мести со стороны обиженного начальства. И, конечно, одного честного слова начальства тут будет недостаточно. Одно из решений — анонимная обратная связь. Но и этого недостаточно, ибо все понимают, что очень часто критика легко вычислить просто по стилю письма…
Теперь по поводу обид на то, что «мы уже говорили об этой проблеме в мае, но воз и ныне там – в этой компании ничего не происходит». Если программистам дается новое задание, то предполагается что от них будут поступать какие-то сведения о продвижении дела. Ну, типа «мы сможем взяться за ваше задание через три недели — у нас уже есть очередь». Через три недели: «Мы взялись за задание, предполагаем сделать через месяц». Еще через две недели: «Работа идет по графику, но возможна задержка на три дня», ну и так далее. Нужна прозрачность. И это же хочется видеть у руководства. Программисты пожаловались, скажем, на то, что новые правила работы с документами отнимают слишком много времени, и в ответ, помимо «Спасибо, мы учтем ваше мнение» хочется слышать что-то конкретное — когда и как это будет рассмотрено и т.п.
Ну, и последнее. Я работю в Штатах, и мне совершенно дико слышать про штрафы сотрудников. Здесь такого нет, и я не понимаю, зачем они нужны. Если в результате клиент получил плохой продукт, то проблема лежит в процессе, который допустил это (а где QA? ) и в руководстве, которое такой процесс создало. Вина общая, штрафовать никого не надо.
Стабильный код нужен для поддержки рабочей версии. Эта модель очень хороша для задач, в которых существует одна текущая версия. Например, для веб-аппликаций. Или для корпоративных систем. В этих ситуациях одновременно идет разработка ноё версии (или даже нескольких), и срочное исправление багов, а также внесение срочных изменений в рабочую версию. А как еще вы предлагаете организовывать разработку в таких случаях?
В очень примитивных случаях — да, так можно делать. Но в общем случае это может быть проблематично: транк мог уже сильно измениться, отделять только нужные изменения муторно и небезопасно (можно случайно занести лишнее изменение и получить новый баг), да и, в конце концов, место, где был баг, может просто измениться до неузнаваемости. Поэтому в качестве общего правила гораздо надежнее изменять на ветке поддержки, и потом мерджить в транк, или в ветку разработки (в зависимости от выбранной стратегии веток).
А почему в одну сторону? Ну вот, например, стратегия, которую Вы упомянули: разработка в транке и ветки для релизов. Отвели ветку для релиза, а потом на ней нашли несколько небольших багов. Естественно их исправить на ветке, и потом мерджнуть исправления в транк.
Ветки зло, когда их делают хаотично и неумело. При правильном подходе ветки — благо :)
Долгоживущая параллельная ветка без мерджей — это, конечно, зло и типичный пример того, как ветками пользоваться не надо. С другой стороны, стратегия при которой, например, стабильный код живет в транке, а на каждый спринт (если мы используем SCRUM) создается своя ветка, которая живет несколько недель, а потом вливается в транк — хорошая и правильная стратегия.
Вообще-то мне кажется, что такой большой рефакторинг лучше делать на отдельной ветке. Сначала на отдельной ветке делается рефакторинг, а потом делается merge в основную ветку. И никакого существования параллельно двух систем.
Я считаю, что бесплатное тестовое задание (если от него вообще есть хоть какая-то польза) должно занимать не более 4-6 часов. Принадлежит оно, скорее всего, соискателю, хотя я на 100 процентов не уверен.
Другой пример — разработка игр. Без project manager'a скоординировать работу сотни очень разномастных людей просто нереально. В этом случае он является каналом для общения с заказчиком — иначе будет полный хаос, и, опять-таки, конструктивного общения не получится.
Проблема в том, что заказчик зачастую не знает сам до конца, что именно он хочет, и совершенно не может внятно сформулировать это. Опытный разработчик постарается объяснить это заказчику. В рамках хлебной аллегории, я как заказчик хотел бы, чтобы разработчик не относился к моим требованиям формально, а сразу поинтересовался: «Хлеб ведь, наверное, в печке надо будет печь?»
И да, конечно, если заказчик категорически настаивает на том, что печка не побнадобится, то делать печку не нужно. Хотя, пожалуй, и из этого правила есть исключения.
А еще надо сказать, что вот такой подход — сделать с точностью до буквы то, что сказали, и ни на йоту больше — заказчиков, как правило, сильно раздражает. И думается мне, что после очередной итерации закачик плюнет, да пойдет искать того, кто будет помогать ему, а не формально делать только то, что сказано.
Далее. Там, где Вы говорите о продажах, правильнее было бы говорить о монетизации. Игру в наше время необязательно продавать — можно крутить рекламу, торговать виртуальными предметами, делать подписку… Есть масса вариантов.
Потом, Вы как-то смешали роли издателя и дистрибьютора, а это, в общем, разные роли.
Следующий вопрос — о раскрутке. Вы его вообще обошли стороной, а на самом деле это — один из очень болезненных вопросов для инди-разработчиков, и на него надо начать отвечать примерно одновременно с началом разработки.
Ну и с «Платить надо за труд, а не за имя» тоже не все гладко. Имя уменьшает затраты на рекламу и риск. Понятно, что с «именем» работать гораздо легче, получить его выгодно, это хотят многие — ну, а следовательно, и цена растет. Закон рынка.
Теперь по поводу обид на то, что «мы уже говорили об этой проблеме в мае, но воз и ныне там – в этой компании ничего не происходит». Если программистам дается новое задание, то предполагается что от них будут поступать какие-то сведения о продвижении дела. Ну, типа «мы сможем взяться за ваше задание через три недели — у нас уже есть очередь». Через три недели: «Мы взялись за задание, предполагаем сделать через месяц». Еще через две недели: «Работа идет по графику, но возможна задержка на три дня», ну и так далее. Нужна прозрачность. И это же хочется видеть у руководства. Программисты пожаловались, скажем, на то, что новые правила работы с документами отнимают слишком много времени, и в ответ, помимо «Спасибо, мы учтем ваше мнение» хочется слышать что-то конкретное — когда и как это будет рассмотрено и т.п.
Ну, и последнее. Я работю в Штатах, и мне совершенно дико слышать про штрафы сотрудников. Здесь такого нет, и я не понимаю, зачем они нужны. Если в результате клиент получил плохой продукт, то проблема лежит в процессе, который допустил это (а где QA? ) и в руководстве, которое такой процесс создало. Вина общая, штрафовать никого не надо.
Долгоживущая параллельная ветка без мерджей — это, конечно, зло и типичный пример того, как ветками пользоваться не надо. С другой стороны, стратегия при которой, например, стабильный код живет в транке, а на каждый спринт (если мы используем SCRUM) создается своя ветка, которая живет несколько недель, а потом вливается в транк — хорошая и правильная стратегия.