Отличная идея. Особенно если рассматривать ее не как главный финансовый источник реформ, а как эксперимент для отработки модели будущего общества: все заинтересованные участники сбрасываются деньгами и тренируются выбирать, как разумно потратить общие деньги на полезные проекты.
В этом смысле сторонние участники (готовые вносить деньги, работая в других местах) тоже очень полезны и не нужно закрывать им доступ к проекту. Это так сказать кандидаты в действительные члены))
А как заказчик оплачивает работу? Почасово, позадачно или еще по какому принципу?
Интересное наблюдение.
А как вообще оценить производительность труда программиста и команды в целом?
А бывает выгорание не от перегрузок, а от других причин: управленческие ошибки, несправедливость по отношению к Вам или к другим, несовместимость с командой ну и т.п.?
Уважаемый Сергей, я бы с удовольствием погрузился в обсуждение механизмов, управляющих работой команды. Тем более, что есть множество теорий и практик в этой области.
Но в данном случае я не пытаюсь понять почему команда лучше функционального управления.
Я пытаюсь понять почему действующая система управления не срабатывает и во многих случаях приводит к выгоранию сотрудников? Посмотрите ленту вокруг: сколько людей признается в проблемах, ходит к психологу и пьет депрессанты.
Почему система коллективной ответственности не срабатывает и по факту приводит к коллективной безответственности?
Кто в общей системе должен работать предохранительным клапаном? Тем, который не мешает работать системе, но обязательно срабатывает в критической ситуации.
Вот в чем вопрос.
Вы правы, в идеале — не должно быть, должна быть единая команда. Но если клубок ведет к руководству, то у руководства тожа должен быть кто-то отвечающий перед ними за успех проекта.
Давайте я Вам приведу один исторический пример.
Когда-то давно Сталину нужно было раздать награды советским ученым, разработавшим атомную бомбу. Вождь решил проблему очень просто: он спросил, кого бы мы репрессировали, если бы проект был провален?
Ему быстро предоставили список кандидатов.
Вот их и награждайте, — сказал вождь, раз они отвечают за неудачу, значит и успех — тоже благодаря им.
Вопрос: кому руководство компании будет снимать голову, если с проектом и командой что-то пойдет сильно не так?
Евгений, Вам может это показаться странным, но и в автомобиле, и в вертолете и в танкере движение сильнее всего зависит от водителя (пилота, рулевого). А уже потом — от всех остальных.
Но это так, к слову.
Вы правы, я пытаюсь найти ниточку, потянув за которую можно постепенно распутать весь клубок.
Успех работы команды всегда зависит от многих факторов. Ну, например, кто-то же нанял этих людей на работу, а кто-то нашел клиента, ну и так далее.
Но среди этих много всегда есть кто-то от работы которого успех зависит чуть больше, чем от других.
Вот я и спрашиваю кто кандидат на первое место по нагрузке и ответственности? Это тимлид или кто-то другой?
Тогда правильно ли я Вас понял, что в ИТ проектах главное звено от которого зависит успех — это тим лид, от работы которого зависит стабильная успешная работа команды? (как от прораба в строительстве).
А все остальные только обеспечивают, поддерживают, улучшают, снабжают заказами и т.п.?
Я правильно понял, что в описанной ситуации проблемы начинаются после того, как процесс стал настолько предсказуем, что команда перестает сама участвовать в процессе планирования (то есть нарушаются процедуры скрама) и сбрасывает этот процесс на менеджера, который рано или поздно, но оторвется от реальных возможностей команды?
Спасибо. Этого достаточно.
Тогда поправьте меня пожалуйста:
управление проектом — это понимание того, что и как нужно сделать в проекте, чтобы дотащить его до следующей точки
управление командой — это понимание того, КТО конкретно и что сделает с учетом всех возможных нюансов (квалификация, настроение, степень усталости и т.п.), а потом сделать так, чтобы это было сделано.
Вы согласны с этими утверждениями или хотите их подкорректировать?
Правильно ли я Вас понял, что скрам (если его правильно использовать) придуман, как система достижения взаимных договоренностей между заказчиком, командой и ПМ.
Разработчики, составляющие команду в идеале являются равноправным партнером переговоров, которые должны и могут принимать на себя только те обязанности, которые гарантированно готовы выполнить. А менеджер должен быть арбитром, который разруливает конфликты и сглаживает противоречия.
А корень проблем в том, что сами разработчики обладают пониженной защитой своих интересов (интроверты, не любят общаться, не учили коммуницировать) + боятся показаться непрофессионалами и поэтому предпочитают перебрасывать ответственность на ПМ в расчете на то, что он добрый и «должен понимать что можно, а чего нельзя».
А ПМ недостаточно обучены как управленца, да и Заказчики давят, поэтому ПМ предпочитают перебрасывать на команду требования заказчиков без всякого разруливания конфликтов.
В результате создается постоянное давление на разработчиков, которое рано или поздно дает нервный срыв?
Так проблема в том, что менеджер не умеет строить отношения с руководством и заказчиком? И поэтому все валит на команду? Или проблема в том, что члены команды плохо умеют выражать свои мысли, защищать свою точку зрения и позволяют на себя давить?
К сожалению, мнение психологов нужно проверять под микроскопом. Они слишком заинтересованы в том, чтобы человек подсел на их сервис((
Сколько людей в этой ленте после обращения к психологу решили свои проблемы и больше не пьют лекарств и не возвращаются к психологу регулярно?
Почитал про шардирование, Интересно. Особенно в части проектирование структуры базы. Что касается менеджмента, то не понял Вашей мысли. Все равно ведь кто-то отвечает за проект в целом, кто-то за его часть, а кто-то за всю компанию. Может не быть прямого подчинения, но должна же быть какая-то иерархия ответственности?
Психотерапия и лекарства — это борьба с симптомами: как выключить чувства, смириться с тем, что произошло и сделать так, чтобы мне было пофиг.
Настоящая проблема скорее всего лежит в области осознания себя: мои сильные и слабые стороны и что из этого вытекает. Что я люблю делать? В каких областях я считаю себя экспертом и мое мнение является превалирующим? Где мое слабое место на которое могут надавить и как от этого защититься? Как научиться говорить нет, чтобы защитить свои интересы? Как отстаивать свою точку зрения? Ну и так далее.
То есть исходная причина: кто-то надавил Вам на слабое место, а сказать Нет и защититься не смогли. Произошел кризис, усугубленный самоедством.
Чтобы восстановиться, нужно отмотать обратно: найти свои сильные стороны и создать защиту. Тогда снова появится вкус к жизни.
Правильно ли я Вас понял, что кроме плохого управления командой есть еще и вторая сторона медали: скажем так пока без ярлыков — низкий уровень самосознания программиста? Когда он плохо знает свои сильные и слабые стороны, боится говорить «нет», не умеет отстаивать публично свою точку зрения и т.п. В результате чего боится показаться команде неумехой и поэтому постоянно принимает на себя либо то, чего он делать не хочет либо завышенные по сравнению с тем, что может обязательства. И поэтому живет в постоянном стрессе? Что в конце концов приводит к выгоранию.
Книга хорошая. Ей действительно 500 лет и она действительно все еще актуальна, как пример методологии управления.
Но нужно понимать, что книга писалась как секретный справочник для царей в те времена, когда захватнические войны, заказные политические убийства, показательные казни подданных, отравление приглашенных Вами на ужин конкурентов и прочие подобные шалости были нормальным средством достижения цели.
Выдергивать из нее отдельные куски и пытаться привязать их к практике стартапов — это очень спорное решение. Уж лучше бы тогда выдернули тот кусок в котором обсуждается как государю строить свои отношения со своим министром. Сюда еще как-то можно вписать модель взаимоотношений лидер-технолог, а ля «Джобс — Возняк».
Но секрет живучести книги вовсе не в этом. Просто Маккиавелли докопался до таких глубинных моделей поведения людей, что прошло вот уже 500 лет, мир изменился, а эти модели поведения остались стабильными. Люди в своей массе остались теми же — вот почему книга актуальна. А методы управления людьми изменились, поэтому бездумно переносить их из книги в практику не советую.