Topic: Новый подход к управлению проектами (Read 183 times)

1. Хорошие программисты сами выбирают работу, а не работодатель их.
Если вы сообщите о вашем плане на собеседовании, вероятнее всего к вам пойдут новички, в лучшем случае, так как никто не хочет изначально работать в стрес ситуациях.
2. При системе голосования коллег - важно будет людям понравится и идти в ногу, а темп всегда задается теми кто слабее, итог вы даже из сильных получите в лучшем случае средний уровень.
3. Есть уже разработанные методологии управления командами, изучайте agile (направления scrum, kanban) и делайте выводы сами, а не опирайтесь на своих коллег программистов, у них другая задача.

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


есть небольшой опыт и понимаю что в 60% фирмах менеджмент проектов намного хуже

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

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

Выскажу свок любительское мнение, т.к. не занимался подобным.

Во всем этом есть одно но, к Вам не пойдут хорошие программисты, так как у Вас нет особо хорошего авторитета и репутации нормального работодателя, после такого психологического экспиремента, то вряд ли она появиться 

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

Далее вот этот нюанс неправильный:


Люди это не ангелы, как там в фильме говориться относитесь к людям проще, а на вопросы смотрите ширьше. Мир тоже не идеален.

Есть места в построении кода, где застопориться, а есть места, где наоборот ускоряется и тут скорее нужно смотреть средние сроки.

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

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

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

Недавно пришла мысль как организовать управление командой программистов в проекте
кратко опишу так

есть проект, есть бюджет, например 6000уе, надо 2 или 3 программиста(зависит от квалификации, если высокая то достаточно 2х)

например 3 программиста, каждый получает 2000 уе в мес, или 500 в неделю
1) прошла первая неделя, работа движется хорошо, без локов, каждый получил по 500(в конце недели каждый готовит отчет, что было сделано)

2) вторая неделя проблемная, все получили по 500уе , 1 или 2 прогера не сделали что надо, в отчете проблемы, руководитель начинает думать как мотивировать, предлагет сделать голосование, если проголосуют за временное исключение одного программиста, то его исключают и исчут нового
например, двое(А и Б) проголосовали против Г, его в запасник и на третью неделю находим нового Д

3) конец третьей недели, если все двигается ок, тогда ничего не делаем, если снова не успеваем, голосуем и смотрим отчеты,  выкидываем того кто не вписался в график, если никто не проголосвал за исключение, тогда исчем четвертого программиста(или берем старого), все получили по 500 уе - штраф за торожение

4) 4 программиста работают за 400 в неделю, если работа движется по графику, то отдыхаем, если опять проблемы с отчетами - анализируем
если 1 программист тормозит и голосование - 3 против одного , исключаем его, ищем нового или оставляем троих(зависит от того, надо ли ускорить разработку), оплата уменьшается пропорционально  сделанной работе, (сделали 80% от недельного плана , получат с коэфф 0.8 )

основные проблемы в такой схеме
1) программситы не заинтересованы в работе, будут медлить, проект загнется
решение, анализировать отчеты и делать ротацию кадров, можно нанять только 2х и они будут получать по 3000уе , увеличить бюджет, задача - найти такого, который будет делать план за неделю(двоих лучше)
2) если двое вкладываются в план, но надо еще один - занимаемся тогда постоянным поиском, если за 2000 уе нет желающих работать - увеличиваем бюджет, например 9000уе на троих, следующую неделю двое получают повышенную зп, рекламируем, хайпим, и обязаетльно должен найтис такой, который разбавит команду с зп в 4500

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