Электронные письма, которые решают задачи на вашем проекте (перевод)

How to Write Emails that Solve Problems on Your Project Оригинал: https://pmbasics101.com/emails-project-management/ Как писать электронные письма, которые решают задачи на вашем проекте Сколько электронных писем в день вы пишете? 10? 50? Всегда ли вы получаете ответ, который ожидаете? Я уверен, что нет. Некоторые письма остаются без ответа, ответ на некоторые приходит не по существу письма, некоторые письма превращаются в бесконечную переписку с большим количеством нерелевантной информации и получателей. Это нормально, многие из нас были в этой ситуации. Но хуже всего вот что: вы не видите проблему в таком положении вещей в вашей рабочей переписке Уровень эффективности вашей переписки очень низкий. […]

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 — эмоциональный взгляд

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

Continue Reading

Главная не финансовая проблема роста IT компании

Вот любят люди делиться на группы, племена со своими признаками, атрибутами, кодексам поведения и прочим. Если компания начинает расти, то неизбежно образование “кланов”, то есть различных отделов, со своим менеджментом, лидерами и враждебностью к другим отделам, которых принято считать врагами и конкурентами. К сожалению, руководство негативные эффекты этого процесса либо не замечает вовсе, либо не понимает что их причиной является именно он. Руководители отделов начинают увлеченно играть в офисную политику, формировать альянсы и рассказывать втихаря руководству, какие плохие другие отделы. Эффективность взаимодействия очень сильно страдает и снижается для минимально необходимой, чтобы не быть явно обвиненным в саботаже, хотя неявный саботаж может […]

Continue Reading

Несколько тезисов об оценке трудоемкости

Собирал я тут информацию об оценках трудоемкости в веб разработке, описывал стандартные проблемы и ошибки. Вот часть получившегося документа, может кому-нибудь будет полезно: Обычные проблемы при выполении заданий (нетехнические), которые существенно влияют на сроки. разрастание объема работ (scope creep) оптимистичность в плане качества (заработает с первого раза и с правильным результатом) не учтено время на необходимые вспомогательные задачи (настройка окружения, базы, выкатка, проверка и так далее) неправильно понята задача, недостаточно подробное или конкретное описание запланирован неправильный объем работ (как следствие предыдущего пункта) проблемы с коммуникациями слишком оптимистичная оценка из-за страха назвать оценку, которая не понравится руководству Давайте разберем, что делать […]

Continue Reading

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

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

Continue Reading

Разработка vs бизнес

Начну с отвлеченного, но полезного — прекрасный сайт с набором видео с различных IT конференций и, что очень полезно для тех, кто быстро читает, транскрипцией этих самых видео, то есть больше не надо слушать унылый голос докладчика, можно просто прочитать и выделить самое важное намного быстрее http://profyclub.ru Теперь, собственно, по теме поста: я столкнулся с тем, что часто веб разработку рассматривают в отрыве от бизнеса в целом, выделяя как что-то малопонятное и загадочное. Стандартная ситуация: менеджер придумал фичу и уверен, что внедрить ее — дело пары часов, а потом недоумевает, почему это занимает неделю или он, наоборот, думает, что на это понадобится неделя, а […]

Continue Reading

Управление и развитие

Вы можете либо управлять существующим проектом/компанией/командой, либо двигать вперед. Очень малая часть вашей активности будет направлена на обе эти задачи. Вы можете устанавливать новые бизнес процессы, оптимизировать задачи, расходы, управлять временем сотрудников, а можете планировать, ставить эксперименты, выходить на новые рынки, исследовать новые ниши, рисковать, инвестировать в новый продукт, новый способ. У каждой активности свои плюсы и минусы. Хорошо, если ваша управленческая команда идеально сбалансирована и вы вместе прекрасно справляетесь с этими задачами не подавляя друг друга, без излишней критики, только с продуктивными конфликтами. Когда “администратор” вашей команды не ограничивает сверх меры “предпринимателя”. С сожалением отмечаю почти полное отсутствие новых […]

Continue Reading