И да и нет. С одной стороны, это же рабочая переписка - ничего личного. С другой стороны делать такое действительно неприятно. Чтобы такие истории возникали как можно реже, я широко использую чаты или каналы, где есть как минимум 3 человека. Если нет подходящего - создаём. Типовой вариант - на каунтерпарта, меня и исполнителя, кого в конечном итоге вопрос и блочит.
Канбан — это не методология, это средство визуализации
Когда мне на собеседованиях заявляют такое, это сразу жирный минус либо умению собеседника формулировать свои мысли, либо его знаниям agile-методологий.
Ну и ставить Agile Manifesto на одну доску с методологиями разработки - так себе идея.
Это целевая история, к которой надо ещё прийти и выстроить всё так, чтобы доверие действительно себя оправдывало. Тут ключевой момент, чтобы у руководителя, который расставляет приоритеты и доверяет задачи другим людям, были адекватные ожидания от их поведения и результатов работы. Как следствие — за сценой много пипл-менеджмента и кропотливой работы с процессами. Либо везение — когда коллектив счастливым образом сложился из ответственных и увлечённых людей, которые друг друга дополняют. Но и тут за везением обычно стоит кропотливая работа того, кто команду собирал.
Во-первых я бы не стал ставить диагноз dev и qa. Во-вторых я говорил о dev lead и qa lead. А в-третьих, переговорные навыки — это про soft skills, о чём я упомянул в п.3. И да, конечно, переговорные навыки обязательно нужны и пиэмам и лидам.
1. Основное требование к Project Manager — успешный проект. Для этого он должен уметь подобрать команду, организовать процесс, поставить задачи и контролировать их исполнение. Способность хорошо контролировать исполнение встречается не часто.
2. Следствие из п.1 — Project Manager должен отвечать за результат. За всё, что происходит на проекте. Не все менеджеры демонстрирую такое понимание.
3. Project Manager должен обладать хорошим набором soft skills — управлять проектом без people management проблематично.
4. Project Manager должен уметь быстро учиться. Чтобы кто ни говорил, нельзя управлять проектами, не разбираясь в предметной области.
5. Project Manager должен знать английский язык хотя бы на уровне Intermediate. Даже если он работает не в международной компании, на русском в сети есть далеко не всё, что нужно для успешной работы на этой позиции.
По моему опыту лучшие Project Manager получаются из Dev Lead или QA Lead. Однако текущий рынок труда таков, что никакой материальной мотивации дев лиду переходить в пиэмы нет. В связи с этим всё чаще приходится сталкиваться с пиэмами, которые никогда руками не щупали разработку. Это, конечно, несколько усложняет взаимодействие с командой разработки и требует более изощрённых процессов.
DEADStop а можете дать апдейт на 2020 год — налоговая попрежнему подкладывает файлы задним числом или на свежие дельты уже можно полагаться без оглядки на прошлые?
В середине 90х у нас на заводе в отдельной комнате стояла новейшая графическая станция Silicon Graphics, которую купили специально для работы с каким-то дорогущим инженерным софтом, в серверной жили серверы SUN, а дома замечательный Amstrad PC 1512, который выпускался и под маркой Schneider www.z80.eu/amstradpc.html
Я бы в этом видел не столько тулу для пиэмов, сколько инструмент для пиди и прочих управленцев чуть более высокого уровня. Наличие таких инструментов у их подопечных сразу снижает уровень требований к ним + даёт возможность контролировать/проверять ход выполнения конкретного проекта начальством. Так что тут вырисовывается b2b продукт, по-моему.
Как-то тоже дошёл до мысли, что деятельность руководителей проектов на определённых этапах хорошо формализуется. Сделал набор похожих списков. А дальше мысль ушла в сторону автоматизации. Типовые этапы (открытие проекта, закрытие этапа, организация массового выезда на сайт и т.п) хорошо ложатся на сценарии типа тех, что есть в современных CRM. Но корпоративную CRM с этой целью использовать не получилось, а писать всё на VB для аутлука рука не поднялась. Думаю, Ваши чек-листы могут стать основой для управленческой библиотеки сценариев для какой-нибудь тулы с тасками и элементарной автоматизацией.
Я бы пользовался голосовой озвучкой спортивной ленты новостей. В машине. На радио новости идут блоком по 5-7 минут, потом много пустых разговоров. А тут, если кто-то будет начитывать новостную ленту некоего издания или агрегатора и снабжать каждую новость тэгом с видом спорта и темой, то будет замечательный спортивный информатор. Каждая новость — микро выпуск подкаста. Ну, мне нравится спортивные новости, кому-то будут интересны политические, экономические и т.п.
Тут мысль совершенно в другом. Попробую ещё раз. Топик стартер говорит, что есть некие пацаны, мнение которых является мерилом качества труда программиста. В пределе — «пиши так, чтобы им понравилось». Ок, если им понравилось, а я сам неудовлетворён — это хорошо или плохо? И наоборот — мне нравится, что я сделал, а пацаны нещадно критикуют? Конечно, получить от грамотных коллег фидбек на свой код — это здорово. Но работать только ради одобрения со стороны — это прямой путь к серьёзным комплексам.
Вам не кажется, что эта конструкция не везде должна работать? Если речь идёт о заказном проекте, то цель — не сделать лучший в мире продукт, а сделать с минимумом затрат то, что удовлетворяет требованиям заказчика. И если на определённом этапе, когда некую задачку можно решить quick & dirty, программист будет делать «чтобы пацанам было не стыдно показать”, в ущерб срокам, то вряд ли это правильный подход. И потом, зачем нужно ориентироваться на мнение неких сторонних пацанов, когда есть своё собственное мнение? И со временем всё меняется. Очень многие состоявшиеся разработчики сегодня не могут без слёз смотреть на свой код 10-летней давности. «Перед пацанами» вроде как должно быть стыдно. Но этот кривой код 10 лет назад позволил запустить стартап или решить сложную задачку в сжатые сроки и спасти репутацию заказчика. «Пацаны» могут курить в сторонке, если я сам знаю, что и зачем я делаю. Разве нет?
Захотел как-то очень крупный заказчик сделать прозрачной процедуру оценки проектов в рамках своей большой программы. И выбрал он CocomoII. Проговорили, прописали и протестировали все параметры и метрики с поставщиком решений. Готовились к переходу около полугода. В итоге получили результат, устраивающий всех — заказчик начал думать, что понимает, как оцениваются его проекты, исполнитель повысил маржу. Очевидно же, что почти любой системой оценки можно манипулировать.
В материале есть несколько неозвученных допущений. В частности, нет ничего про изменение требований. На практике не встречал ни одного проекта, чтобы заказчик не менял требований. А это уже работа по управлению изменениями, что делает задачу нелинейной. Так же просматривается допущение, что мы как-то можем влиять на сроки проекта. Вероятно, в продуктовом мире это так и есть, но в деливери-мире после заключения контракта сроки проекта уже зафиксированы, и всё, чем мы можем управлять — это технологии и команда. И тут остаётся только верить, что на этапе оценки были учтены все риски, а руководитель проекта грамотно разрулит все запросы на изменения.
Оценка проектов — это отдельная большая тема. Даже если предположить, что техлид/архитектор/команда/иное, оценивающий проект, хочет это сделать максимально объективно, всегда есть внешнее давление или соблазн завысить оценки/подстраховаться. Сейлы, принимающие участие в утверждении оценок, всегда стремятся занизить оценку (снизить себестоимость, увеличить свои бонусы). И тут всегда имеет место борьба/игра. Так что тема миграции специалистов между командами, безусловно, полезна, но решающего значения при оценке проектов это иметь не будет. Нужно всё решать, опять же, проектированием правильных процессов и мотивацией.
Вот не согласен с «Забудьте слово «ошибка». Во-первых иногда бывают именно ошибки с выбором людей. И их нужно как можно быстрее распознавать, признавать и исправлять. Вы привели много правильных критериев для формирования команды, но достоверно всё это распознать зачастую помогает только время. Во-вторых, если мы уже когда-то сделали что-то не так, зафиксировали это, провели lesson learn, а кто-то, тем не менее, второй раз наступает на те же грабли, третий и т.п., то это тоже ошибки. Разной степени тяжести и разными последствиями для тех, кто их совершает.
Мобильной версией не пользуюсь по причине отсутствия в ней оффлайн-режима. А как было бы прекрасно в самолёте почитать то, что автоматически закачалось за последние пару суток.
Конечно, в Яндексе и любой другой большой продуктовой компании должна быть своя специфика по сравнению с заказной разработкой и некоторыми другими видами IT-компаний. Но при этом возникает вопрос — а корректно ли называть проектами то, что они делают? Предположу, что к подавляющему большинству их активностей больше применима процессная терминология и KPIs, а не проектные. Тогда всё становится на свои места.
И да и нет. С одной стороны, это же рабочая переписка - ничего личного. С другой стороны делать такое действительно неприятно. Чтобы такие истории возникали как можно реже, я широко использую чаты или каналы, где есть как минимум 3 человека. Если нет подходящего - создаём. Типовой вариант - на каунтерпарта, меня и исполнителя, кого в конечном итоге вопрос и блочит.
Эхх... и незабвенный журнал Монитор с конкурсами и задачками на оптимизацию ассемблерного кода.
https://youtu.be/SEl_RvMIjeQ Death Track - это была бомба. Даже в чёрно-белом варианте
Когда мне на собеседованиях заявляют такое, это сразу жирный минус либо умению собеседника формулировать свои мысли, либо его знаниям agile-методологий.
Ну и ставить Agile Manifesto на одну доску с методологиями разработки - так себе идея.
Это целевая история, к которой надо ещё прийти и выстроить всё так, чтобы доверие действительно себя оправдывало. Тут ключевой момент, чтобы у руководителя, который расставляет приоритеты и доверяет задачи другим людям, были адекватные ожидания от их поведения и результатов работы. Как следствие — за сценой много пипл-менеджмента и кропотливой работы с процессами. Либо везение — когда коллектив счастливым образом сложился из ответственных и увлечённых людей, которые друг друга дополняют. Но и тут за везением обычно стоит кропотливая работа того, кто команду собирал.
1. Основное требование к Project Manager — успешный проект. Для этого он должен уметь подобрать команду, организовать процесс, поставить задачи и контролировать их исполнение. Способность хорошо контролировать исполнение встречается не часто.
2. Следствие из п.1 — Project Manager должен отвечать за результат. За всё, что происходит на проекте. Не все менеджеры демонстрирую такое понимание.
3. Project Manager должен обладать хорошим набором soft skills — управлять проектом без people management проблематично.
4. Project Manager должен уметь быстро учиться. Чтобы кто ни говорил, нельзя управлять проектами, не разбираясь в предметной области.
5. Project Manager должен знать английский язык хотя бы на уровне Intermediate. Даже если он работает не в международной компании, на русском в сети есть далеко не всё, что нужно для успешной работы на этой позиции.
По моему опыту лучшие Project Manager получаются из Dev Lead или QA Lead. Однако текущий рынок труда таков, что никакой материальной мотивации дев лиду переходить в пиэмы нет. В связи с этим всё чаще приходится сталкиваться с пиэмами, которые никогда руками не щупали разработку. Это, конечно, несколько усложняет взаимодействие с командой разработки и требует более изощрённых процессов.