Как стать автором
Обновить
17
0

Пользователь

Отправить сообщение
Если имеется в виду просто работа из дома (в офис не ходим), то здесь отсутствует такой момент, как возможность выбора заказчика (перехода в другой проект).
Очень точная и ёмкая формулировка:)
Да, похоже необходимо пояснение. Имелась в виду, что в разработке как раз очень важно заинтересованное участие разработчика в процессе. Именно он, а не руководитель может знать лучший подход в решении возникшей проблемы. Цель PM — дать проявиться этой творческой инициативе. Или, если не можешь помочь прорасти, хотя бы не давить.
Ну имелось в виду известное сравнение процесса разработки ПО с фабрикой. И разработчики противопоставлялись занятым на конвейере рабочим.
Никого не хотел обидеть.
Сначала подумал, что по 5-ти балльной шкале. Потом понял, что ашипся:)
В реальности, чтобы такое заработало — надо просто взять и сделать ;) Да, рискованно; да, страшно, но без практического внедрения это все остается только идеями и далее ни куда не уходит…


Согласен. Для того и хочу рассмотреть эту идею с разных сторон. Хочется попробовать внедрить её в нашей компании.

Спасибо за ваши комментарии. Какие-то вещи я начал представлять лучше.
Попробую пройтись по «минусам»:

1) В нашем случае — это несколько одновременно идущих проектов со своим PM'ом. Сложность — примерно одинакова. Тематика, технологии — различаются. При этом, периодически возникает ситуация, когда один из проектов требует дополнительных трудозатрат в какой-то период. Обычно это решается указанием сверху — Вася Пупкин переходит из проекта А в проект Б. Что думает Вася — не важно. В общем, во всех конторах, где довелось поработать — всегда были несколько параллельных разработок (просто иногда они практически не отличались одна от другой:)

2) Это как раз тот минус, о котором вы писали, который можно обратить в плюс. Лучше давать человеку свободу внутри компании, чем подавлять его и ограничивать и тем самым подводить к тому, что он просто уйдёт совсем. Не в другой, более интересный проект, а в другую компанию.
Дело в том, что это добавляет прозрачности в отношения компания-сотрудник. Если с одного проекта бегут — нужно разбираться. Но это путь развития. В обычных условиях все просто молчат и работают, пока не устанут окончательно, а тогда уже удержать можно только деньгами, деньгами, деньгами. А как же душа?:)

3) Нахлебники — это плохо. Но! Если продумать, как доносить до всех результаты работы каждого, то это уже становится делом коллектива. То есть, сидят Петя с Колей и впахивают по-стахановски, а рядом Вася — и сёрфит весь день в инете, в проекты не рвётся (устраивает его базовый оклад). Раньше в этой ситуации дёргался только PM, теперь же все понимают, что кормят Васю из своих. И должны будут Васе по-дружески объяснить, что он не прав:) Таким образом — мы и гражданское общество построим!:)

4) Почему санкции это не хорошо? Как я понимаю, они могут возникнуть если:
а) Разработчик неверно оценил объём работ и свои силы
б) Расслабился
Если а), то помогаем человеку расти и лучше оценивать. Если б) — воспитываем ответственность (первую сессию тоже многие заваливают, от новизны ситуации — никто не стоит над душой; но потом ведь учатся!)

5) Да PM тоже нужно будет расти. Многие вещи, которые бы раньше прошли и так, теперь придётся планировать по-другому. Ну ничего, можно ведь договариваться с разработчиками не только по fixed-cost, но и по time&materials, для секций, где много неясного и высокие риски (но компании между собой как-то управляются, а мы чем хуже?:)

6) Как разрабатывать ТЗ — сходу не ответишь, нужно подумать. Если совсем правильно, то опять же на договорной основе привлекать архитектора и платить ему денежку. И в этом случае, у нас появляется новый тип проектов — предпроектный Research. Может быть кому-то у нас в коллективе именно этого не хватает для ощущения полноты бытия?:)

Информация

В рейтинге
Не участвует
Зарегистрирован