Рубрика «управление людьми» - 10

Jira против хаоса в разработке: как не терять задачи - 1

В предыдущей статье я рассказал, какие надстройки для Jira мы сделали, чтобы рабочий флоу стал максимально удобным, а тикет — исчерпывающе информативным. В сегодняшней статье мы решим другую задачу.

Дано:

  • вы разрабатываете и поддерживает сложный программный продукт, работающий на нескольких клиентах;
  • у вас несколько инженерных команд (бекенд, IT Ops, iOS, Android, веб и т. д.), которые работают независимо друг от друга с отдельными беклогами;
  • у вас несколько продуктовых направлений, то есть, грубо говоря, один продуктовый менеджер ведёт несколько проектов по своему направлению, другой менеджер — по своему;
  • ваши инженерные команды функциональны, то есть они не выделены на отдельные продуктовые направления, а решают задачи всех юнитов сразу, обслуживая определённую часть технологического стека;
  • и, конечно, вы используете Jira!

Читать полностью »

Денис Пушкин, Head of Product Marketing в Skyeng, рассказал о том, что вдохновляет его на создание и развитие продуктов.

Как применять продуктовое мышление к миру: на примере толстовки - 1

Давайте начнем с того, чем занимается менеджер продукта — это три известных всем области:

  1. IT-продукты — в основном сайты и мобильные приложения.
  2. Операционка — операционные процессы в любых сервисах, например, в колл-центре или доставке еды.
  3. Человек. Самые модные ребята в продуктовой тусовке прокачивают себя как продукт.

Этим списком все ограничиваются, потому что непонятно, а что еще можно прокачать как продукт. Но мне кажется, что менеджеры продукта думают слишком узко о том, чем они занимаются. Менеджер продукта — не профессия, а состояние души или mindset. Mindset — это набор ваших убеждений, которые вы применяете где угодно.
Читать полностью »

Я думаю руководители отделов IT департамента согласятся со мной, что иногда кажется, что мы находимся на границе двух миров, живущих по разным законам, в разных временных ритмах, а нам приходится жить в обоих этих мирах. И, если трансляцию “образа жизни” сверху вниз, от вышестоящих менеджеров до инженеров, мы в силу своих должностных обязанностей осуществляем регулярно, то вот в обратную сторону — увы…

Поэтому этот пост о том, что я, как инженер, хочу сказать нашим дорогим менеджерам и тем, кто считает их “образ жизни” единственно верным. )

Планирование, диаграммы ганта, “следование процессу”, дисциплина, deadline, распорядок, “два раза не объясняю одно и тоже”, “не успел, значит плохо планировал”… — знакомые вещи? Это сущности и методы “мира менеджеров”. Понятно, что где-то больше, где-то меньше и вообще упрощение, но речь не об этом мире. Он безусловно важен. Его методы отлично работают во многих вещах. Но есть огромный пласт задач, где ничего из этого не работает, а работает совсем другое, подчас противоположное.
Читать полностью »

– У нас не получится уложиться в сроки!
– Примените Agile!
– Без достаточного количества людей он нам не поможет!
– Тогда придумайте другое умное слово!

Последнее время часто слышу: они провалились, потому что неправильно выбрали методологию разработки продукта. Вот если бы вы применили Scrum/DevOps/Agile/еще что-то, то все было бы хорошо. Похоже, эти люди кое-что не понимают в разработке софта.

Еще Алистер Коуберн в своей статье проанализировал разные программные проекты, которые выполнялись по разным моделям от совершенно «легких» и гибких до очень «тяжелых» и формализованных. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись. Отсюда Коуберн сделал вывод о том, что эффективность разработки не зависит от модели процесса.

Существуют десятки методологий, но ни одна не гарантирует результат. В каждом новом проекте процесс должен определяться каждый раз заново. В основном, выбор процесса зависит от разрабатываемого продукта и людей, участвующих в разработке. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.
Читать полностью »

Никто не станет требовать от разработчика, чтобы он писал код без доступа к компьютеру, но многие компании считают, что он каким-то образом должен работать без возможности полностью задействовать свои мыслительные возможности. А это примерно настолько же нереально.

12 факторов, которые мешают работать программистам - 1

И поэтому давайте пройдемся по списку из двенадцати вещей, которые не позволяют разработчикам войти в состояние потока и выдать максимальную продуктивность. Я постараюсь двигаться от самых ключевых вещей к менее существенным. Предлагайте свои варианты и замечания!

Если же кто-то сомневается, стоит ли тратить на это деньги и силы, достаточно вспомнить, сколько программистам платят. Даже прирост производительности в 10% — это немало в денежном эквиваленте!
Читать полностью »

Практически все компании сейчас оказывают давление на сотрудников, побуждая их работать больше часов, чем указано в договоре. Это давление маскируется разными эвфемизмами: красивыми словами про миссию, личный вклад, марш-бросок. Те, кто изъявляет готовность перерабатывать, часто получают поощрительные знаки внимания от руководства: «Джо выложился на сто пятьдесят процентов, чтобы помочь нам достигнуть поставленных целей: работал допоздна, выходил на выходных. Он жертвовал своим временем ради нашей миссии».

Переработка вредит и продуктам, и сотрудникам - 1

К счастью, самому мне не приходилось работать в компаниях, где мое отвращение к сверхурочной работе встречало бы неодобрение. И все-таки я считаю, что недопустимо даже отзываться о такой практике одобрительно. Это симптом проблем, которые нельзя поощрять. Ни при каких обстоятельствах.

По сути своей, необходимость в переработке происходит от проблем с профессионализмом, расстановкой приоритетов и гибкостью. Я, по большей части, буду говорить о сверхурочной работе в IT компаниях, но то же самое негативное влияние на продуктивность и качество работы можно наблюдать и в любой другой сфере.
Читать полностью »

Это философская заметка про управление и воспитание, а также про очень неожиданное озарение связанное с моделированием цифровой плесени. Навеяно беседами о проблемах управления строительством, а также сетью существенно удалённых филиалов.
image
Борьба популяций цифровой плесени под воздействие испепеляющего солнца.

Предуведомление. Статья состоит из трёх частей, и первые две кажутся вообще друг к другу никак не относящимися, однако есть третья объединяющая их.
Читать полностью »

image

Дела у вас пойдут плохо, если не контролировать качество продаж. Причем контроль нужно внедрять до оценки качества.

Часто бывает иначе. Точка приносит мало денег? Отлично, давайте всех уволим. Не будет считать затраты на увольнение, обучение и поиск новых сотрудников. Просто разгоним «плохих» и наберем «хороших».

В результате «хорошие» оказываются ещё хуже. Как так? Управленческие действия опирались на некорректные показатели.

Руководитель должен знать, почему магазин не приносит прибыль. Обычно для оценки качества продаж пользуются услугами тайных покупателей или проводят внутренние аудиты.

У старых методов присутствуют недостатки, которые мы исправили в сервисе оценки действий сотрудников на базе Ivideon.
Читать полностью »

На мой взгляд, данная статья будет интересна тем, кто планирует организовать стартап и при этом нуждается в людях (то есть нет таких друзей, готовых принять участие в проекте). Еще, это полезный опыт для тех, кто занимается наймом в принципе, например, в качестве кейса.
Читать полностью »

Доброго дня!

Как мы уже анонсировали в предыдущей статье про типичные ошибки начинающих руководителей, Станислав Михальский провёл, в рамках нашего курса «Руководитель разработки», открытый урок на тему «Специалист „у руля“: первый опыт и ошибки». В нём он рассказывал о выявлении и решении проблем и вопросов, которые возникают перед линейным сотрудником, получившим руководящую должность и в целом об основных вызовах, ловушках и ошибках начинающих it-менеджеров.


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js