Размер команды и Agile мышление

Продолжаю размышления на тему применения agile практик в реальной жизни. Давайте обсудим зависимость от размера команды проекта.  Photo by rawpixel.com on Unsplash до 4 В этом случае абсолютно неважно какому процессу или методологии следовать, это не окажет почти никакого влияния на результат. Тут и менеджер не нужен, от слова “совсем”. Это хакатон, стартап, что угодно, но не проект. до 7 (±2) В команде проекта пара разработчиков, один тестер, а также парт-тайм аналитик и дизайнер? Допустим, что вся команда около 7 человек. Тут оказывает влияние личностные качества ПМа и его умение работать с людьми. Использование легковесных Agile практик помогает, но еще не является критичным […]

Continue Reading

Путь от разработчика до менеджера

При построении карьеры в определенной области чаще всего выделяют 2 уровня движения: горизонтальный и вертикальный. Горизонтальный — увеличивать экспертизу в определенной технологии или стеке технологий, углубляя знания и получая ценный опыт использования в проектах различного размера и продолжительности. Вертикальный — двигаться в сторону административного управления, увеличивая масштаб ответственности решений и влияния на область деятельности, то есть становясь все более высоким менеджером, вплоть до владельца собственной компании. Первый путь связан с работой с людьми намного меньше, чем второй и это для большинства людей — самое решающее отличие. Тем не менее я хочу рассказать как технарю стать достойным менеджером, с какими проблемами придется столкнуться и каких ошибок стоит […]

Continue Reading

Менеджер проектов — это не руководитель или начальник

Ох уж это советское наследие, до сих пор мы используем слово “начальник” с тем же смыслом, что и 50 лет назад. Еще более любимое мною слово — “руководитель”. Вот прям который за руку ведет всех подчиненных. Почему то даже в продвинутой IT сфере менеджер — это больше руководитель: фасилитирует кучу взрослых людей, следит за правильным перемещением бумажек на доске и считает цифры и отчеты в эксельке. Неудивительно, что разработчики периодически устраивают движения в стиле “менеджеры — бесполезны и нам не нужны”. Где крутые продукты на постсоветском пространстве? Один-два единорога в год? Возьмите цифры по росту прибыли аутсорса у нас и в какой-нибудь […]

Continue Reading

Попытка организовать кросс-функциональные команды (перевод)

Our first take on cross-functional teams Оригинал: https://tech.kartenmacherei.de/our-first-take-on-cross-functional-teams-b0af5476d802 Наша первая попытка организовать кросс-функциональные команды Когда мы только начали переводить разработку в команду внутри компании в 2012 у нас было все просто, за исключением, естественно, усилий по поиску и убеждению талантливых людей присоединиться к нашей тогда еще маленькой компании. Кристоф и Штеффен решали что разрабатывать и в какой очередности. Они также постоянно напрямую общались с командой из трех разработчиков. Когда команда начала расти, мы начали использовать скрам с его типичными недостатками и достоинствами для начинающих команд. В следующие 24 месяца команда выросла до 20 разработчиков, тестировщиков и технических менеджеров продукта и тогда […]

Continue Reading

Постановка задач в разработке крупного новостного портала

Довелось мне выступить на конференции айтишников и журналистов вместе с моей коллегой журналисткой. Рассказывали мы про взаимодействие между отделом разработки и другими на примере взаимодействия с редакцией. Моя часть рассказа заключалась в том, что я давал советы, как правильно ставить задачи разработчикам, если вы не технарь. Ниже привожу текст выступления их моего черновика подготовки к нему (поскольку из черновика, то иногда там я перескакиваю немного): Проблемы взаимодействия технарей и гуманитариев свойственны не только IT, но и другим областям и принципы улучшения коммуникации схожи. Самым простым способом является наличие человека, который бы выполнял роль посредника между внутренними заказчиками и разработчиками, так […]

Continue Reading