Комментарии 41
в проекте работают люди, а не роботы, и всегда возможны и будут варианты, даже если вы нанимаете супер профессионалов, может даже оказаться, что уровень вашего собственного профессионализма ниже профессионализма тех, кому вы не доверяете
поэтому должен быть выстроен процесс контроля за качеством в течение цикла каждого модуля, а не только проекта в целом, а работа руководителя проекта — контроль за этим качеством на каждом этапе и оценка рисков, а не параноидальное «доверие», тем более что в 99% случаев руководитель проекта не может выбирать людей по личному вкусу и работает с тем, что есть, особенно если часть проекта отдается сторонним организациям
Я понимаю, что уровень профессионализма сотрудника может быть выше уровня профессионализма руководителя. Хотя не понимаю как можно сравнивать профессионализм в управлении с профессионализмом в разработке. Но я соглашусь, что такое бывает и считаю такую ситуацию крайне удачной!
Как из вышеизложенного вытекает, что должен быть выстроен контроль качества я тоже не понял. Но соглашусь что да, действительно должен. Чаще всего.
Но не теряйте контекста статьи, а он такой — «как снять с себя непрофильные обязанности и заняться тем чем мне должно заниматься».
необходимость контроля качества вытекает не из вышеизложенного, а из системы управления проектами
снять с себя непрофильные обязанности и при этом обеспечить успешное выполнение проекта невозможно без инструмента контроля за выполнением
если вы не знаете, как выстраивать процесс контроля за качеством, то что вы делаете в руководстве проектом?
Приведу вам ваши же слова:
невозможно контролировать доверие до уровня стопроцентной уверенности в стопроцентном результате
в проекте работают люди, а не роботы, и всегда возможны и будут варианты, даже если вы нанимаете супер профессионалов, может даже оказаться, что уровень вашего собственного профессионализма ниже профессионализма тех, кому вы не доверяете
И далее
поэтому должен быть выстроен процесс контроля за качеством
Вы действительно считаете, что процесс контроля за качеством должен быть выстроен именно «поэтому» или уже не считаете так? :)
Ну и опять таки постарайтесь обосновать ваши выводы о моей компетенции.
плюс косвенно обвинили меня во вранье
думаю, тут все прозрачно
Вы привели очень интересный вымышленный пример с профессионализмом. Такого в моей жизни еще не было. Думаю я бы поучился у такого специалиста, который к тому же имеет существенный опыт в управлении, с большим удовольствием.
Так вроде бы общепринято считать, что начиная с сеньорных грейдов, "разработчики" становятся теми людьми, которые способны объединять в себе функции как непосредственно разработчика, так и руководителя… не?
Эмм…
1) Большинство компаний, как минимум достаточно крупных, придерживаются разделения на Junior, Middle, Senior (а где-то и больше) грейды… при этом есть некие общие черты, по уровням компетенции, использующиеся в разных компаниях… где в настоящее время не придерживаются данной "классификации" в IT компаниях?
2) Что такое в данном случае понимается под "умением руководить"? Ну и в целом Ваше утверждение весьма спорное: без достаточной компетенции в вопросе, менеджер легко может оказаться в роли самодура, не понимающего, какие у команды могут возникнуть проблемы при решении поставленых задач в установленые сроки.
Как раз вчера общался с руководителем, учредителем двух компаний, руководитель направления в одной немецкой компании. Он в итоге пришел к выводу, что руководитель должен разбираться в людях и управлении, но ни в коем случае не должен пытаться сделать дело своими руками — это отвлекает от основной обязанности — управления. Хорошо я он вышел из разработки.
Может ли руководитель оказаться самодуром? Ещё как может! И разработческое прошлое от этого не спасает.
Руководство = управление.
Чтобы наш разговор был более предметным я предлагаю вам описать ваше понимание Senior, а читатели пояснят где ваше мнение отличается от их. И т.к. стандарта нет, то вы ведь позволите им иметь собственное мнение?
Традиционно, как в "одной немелкой компании", в которой я работаю в настоящее время, так и в достаточно большом числе других компаний, с которыми я когда-либо пересекался, вот конкретно эти 3 грейда делят примерно как:
1) Junior — спциалист, который умеет программировать, но не имеет достаточного опыта в инженерии и процессах, в связи с чем может неверно оценивать приоритеты по задачам и работать не достаточно эффективно. Для его эффективной работы требуется супервайзер, который будет учавствовать при составлении roadmap'ов, и контролировать процесс работы.
2) Middle — специалист, который умеет программировать и в целом имеет представление о процессах и углубленную экспертизу в своей области, что позволяет ему выступать в роли эксперта в области своих компетенций внутри компании. Может как самостоятельно заниматься работой над существенными частями проекта, так и выступать в роли супервайзера для джуниоров. При составлении roadmap'ов ему так-же требуется супервайзер, который поможет при расстановке приоритетов.
3) Senior — специалист, который имеет обширную экспертизу, понимает процесса внутри компании. Персонаж довольно автономный, которому достаточно указывать "великие цели" и сроки, после чего он может самостоятельно организоваться сам и организовать коллег, может заниматься непосредственным составлением roadmap'ов, выступать в роли овнера проектов и тд и тп. Может активно учавствовать в митингах с заказчиками и учавствовать в том числе и в составлении глобальных roadmap'ов.
Вот примерно как-то так…
И в компании на ~100 человек у нас это работало, и в компании на ~100K человек все ± то же самое.
Не понимаю, чему вы удивляетесь (уже несколько раз в комментариях) в вопросе "что вы делаете в управлении проектами, если не умеете управлять". В идеальном мире и в большой организации пожалуй да, этим занимается опытный человек. Но в реальном мире очень много небольших команд, в которых отдельный управленец — непозволительная роскошь. Да и работы ему на фуллтайм не найдется. Поэтому, управлением занимается наиболее опытный член команды, который на первых порах как раз и не имеет никаких навыков в этой сфере, учится на ошибках и читает книжки. И "зашивается" так же, как и автор статьи.
Все о чем вы пишите уже описано в книгах по системному менеджменту. Почитайте: всегда проще учиться на чужом опыте. Управление в IT имеет гораздо больше общего со "всем остальным" управлением, чем айтишники привыкли считать.
Идеальный вариант — две команды с тимлидами, чтобы обеспечить одинаковую приближенность к руководителю (себе). Опять же возможность карьерного роста в коллективе (если корп. культура позволяет).
Оценкой своих людей и подбором новых людей в свою команду должны заниматься тимлиды. Иначе вряд ли его/ее будут воспринимать, как руководителя. Про доверие уже поговорили ниже: )
notdotteam.github.io/trust
Нормальный путь нормального человека без специализированного образования в управлении проектными командами. Отлично пишите, правильные выводы делаете. Не ведитесь на тролей и продолжайте развиваться!
Насчет PMBook: будьте предельно аккуратны с этими знаниями, т.к. они загоняют вас в рамки. В IT управлении действительно больше общего с "управлением" чем с "IT", но современные IT продукты создаются сильно по-другому. Тот же PMBook был написан для девелоперов(застройщиков) и хотя его адаптировали в IT очень грамотные люди, но построить здание и создать "современный" програмный продукт, на мой взгляд сильно разные вещи. Почему? У большинства "современного" it-бизнеса часто проблема с однозначной идентификацией бизнес цели. Каким бы вы не были богом менеджмента, с плавающей бизнес-целью предприятия вам не справится самому, темболее на уровне управления проектных команд. PMBook же довольно сильно опирается на стабильность этой самой первичной бизнес-цели. Сведеющие в этой теме, поправьте меня, пожалуйста, ибо читал его уже года 4 назад.
Ну и желаю Вам успехов в Вашем деле и эффективного решения всех проблем! :)
Например, вопрос доверия… Какому ПО мы доверяем больше? Которое успешно прошло тестирование. Особенно, если сценарии написали мы сами (как самые опытные, знающие и т.п.) или кто-то, кому мы доверяем. Так и с человеком. Новичку можно дать задачу и выяснить, как он с ней справляется. Конечно, наши первоначальные ожидания о качестве работы человека, сформированные в ходе собеседования, должны подсказать насколько критична должна быть задача и какой контроль нужно обеспечить на период тестирования новичка.
Трудно сходу довериться новичку. Да и доверие ценится сотрудником выше, если оно заслужено. Поэтому начинать путь к доверию нужно с малого.
чем быстрее хорошие технари приходят к тому, что их тех.навыки применимы и в управлении людьми, тем быстрее они становятся хорошими руководителями
А ведь я с вами согласен. А можете еще раскрыть ваше видение — какие именно «тех.навыки применимы и в управлении людьми»?
Процессы — это правила игры, а Ваш коллектив — группа людей, которая в нее играет. Все должны знать правила и следовать им. Вы создаете эти правила, как отражение накопленного Вами и командой опыта, и обеспечиваете их соблюдение, наблюдаете с судейской вышки и думаете, нужно ли что-то менять…
Разработка и внедрение процессов — вполне технические задачи. Согласны?
Например, то что я описал в предыдущем комментарии о доверии, можно рассматривать как юзкейс/процесс «Адаптация новичка» («Внедрение нового модуля/функционала в работающую систему»).
Как обеспечить соблюдение правил? Следование правилам — это в некотором смысле естественная потребность людей, потому что при наличии правил понятно, что ждут от тебя и что ты можешь ждать от других. Нужно только убедиться, что правила разумны, честны, понятны и подъемны. И не бояться их менять, если пришло время.
И где то там в облаках летают мотивация, эмоциональная зрелость, навыки Ваших людей и т.п. Без учета всего этого будет трудно поддерживать боевой дух в коллективе.
Рассматривайте работу Вашего коллектива как совокупность юзкейсов или процессов, а людей — как объекты, которые их реализуют.
Данное представление как будто упрощает людей. Человеческий фактор не зря считается серьезным источником сложностей. Почему же вы так упрощаете отношения людей? Человек это объект с неизвестным иррациональным поведением. Аналогию с объектами вряд ли можно считать практичной.
Процессы — это правила игры, а Ваш коллектив — группа людей, которая в нее играет. Все должны знать правила и следовать им. Вы создаете эти правила, как отражение накопленного Вами и командой опыта, и обеспечиваете их соблюдение, наблюдаете с судейской вышки и думаете, нужно ли что-то менять…
Тут согласен.
Разработка и внедрение процессов — вполне технические задачи. Согласны?
Я не видел в работе программиста такой работы с процессами, которая помогла бы ему в дальнейшем управлять людьми. Поэтому формально с утверждением я согласен, а вот с вероятным выводом из этого утверждения — нет.
Как обеспечить соблюдение правил? Следование правилам — это в некотором смысле естественная потребность людей, потому что при наличии правил понятно, что ждут от тебя и что ты можешь ждать от других. Нужно только убедиться, что правила разумны, честны, понятны и подъемны. И не бояться их менять, если пришло время.
Соглашусь.
И где то там в облаках летают мотивация, эмоциональная зрелость, навыки Ваших людей и т.п. Без учета всего этого будет трудно поддерживать боевой дух в коллективе.
Согласен. Только тех. навыки тут совсем не помогают.
Давайте вернемся к исходному вопросу — какие именно, максимально конкретно, тех. навыки программиста, коли мы находимся в контексте разработки ПО, помогают ему руководить людьми? Я увидел много слов, но к сожалению не увидел ответа. Могу своё видение описать, но хочу все таки сначала увидеть ваше, чтобы исключить влияние.
Почему же вы так упрощаете отношения людей? Человек это объект с неизвестным иррациональным поведением.
В общем случае — да, действительно, не так просто.
Но человек в коллективе, с которым Вы договорились играть по определенным правилам, как бы встроили в систему, подключили, не так уж и иррационален. Он знает, что от него ждут и что он может ждать от других. И он может через это сам себя оценивать (обратная связь) и корректировать свои действия. Далее все зависит от его/ее опыта, эмоциональной зрелости, воспитанности. Не нужно забывать, что не только руководитель может предъявить претензии о несоблюдении правил игры, но и члены коллектива могут предъявить их руководителю и другим членам команды (иногда такие отношения обретают даже формализованный вид, называются ретроспективами — чтобы коллектив не забывал о своих правах). Если человек идет сознательно (понять это — задача руководителя) на нарушение правил, то справедливо может ожидать, что в отношении него будут применены какие то корректирующие действия. Важно, чтобы правила были прозрачны. И одинаковы для всех. Обеспечение этого — задача руководителя.
Часто за иррациональным поведением (как нам оно видится со стороны) скрывается непонимание/незнание/неумение (тех. навыки), неудовлетворенность.
Итак, коллектив — это система. Процессы — юзкейсы. Строим организацию коллектива — проектируем систему, разбиваем ее на подсистемы (разработка, тестирование и т.п.), модули (команды) и объекты (люди). Инкапсуляция — запрет на микроменеджмент, взаимодействие через интерфейс желательно с известными пред- и постусловиями, инвариантами (контрактное программирование). Нагрузка на команду высокая — вводим балансировщик. Команда продуктовая (должна жить долго) — внедряем DR, дублирование…
Но мысли, точно, годные. Еще раз спасибо.
Ладно, чего я умничаю. Вот моё видение.
Принципы SOLID.
Об ограничении рабочих функций:
- Принцип единственной ответственности
- Принцип разделения интерфейсов.
О взаимозаменяемости кадров, о важности ролей:
- Принцип инверсии зависимостей.
- Принцип подстановки Барбары Лисков.
Я слишком занят чтобы что-либо предпринять