Слышали ли вы когда-нибудь в свой адрес упреки в неконструктивности? Может быть, сами кого-то упрекали? Как вы понимаете, что вот это конкретное обсуждение не конструктивно, а вот это конструктивно?

Если начать думать на эту тему, то тут есть на что потратить пару часов. Эту задачу мы сейчас постараемся облегчить. И в рамках нашей серии статей по управленческим инструментам (ушедшей в отпуск на время новогодних праздников), разберем принципы конструктива, предложенные когда-то Энди Гроувом, одним из основателей компании Intel.

Принципы простые, но объясняют довольно много рабочих и не только рабочих конфликтов. И разобравшись с ними вы:

• Поймете причины поведения своих коллег, руководства и заказчиков в некоторых ситуациях
• Занесете в свой арсенал несколько простых приемов, которые помогут вам легче договариваться по работе
• Сможете абсолютно точно объяснить любому коллеге, что он неконструктивен (и в чем именно), если он действительно неконструктивен

Здесь не будет полюбившихся нам матриц 2 на 2, но пару схем мы разберем.

Вдруг мы понимаем, что Jira превратилась в помойку. Каждый второй РП настраивал Jira как ему было удобнее бесконтрольно. А когда проект начал гореть, начал тушить пожары вручную, оставляя задачи в трекере в каком-то состоянии, далеком от завершения. Если в проекте создан полноценный CI/CD, то большая часть задач на разработку будет в правильном финальном статусе, но остальные…

Часть проектов заморозилась, часть отвалилась, РП выгнали, но задачи в Jira не почистили. У вас на руках 10-20 идущих “проектов” и нужно быстро понять где больше болит.

Сопоставив опыт участников посиделок КиФБ (клуб имени Фрэнсиса Бекона) в решении этой задачи, мы представили этот опыт в записанном виде (за что спасибо всем участникам).

Как следует из названия, это продолжение серии статей про роли в scrum (часть 1 и часть 2). Сегодня рассмотрим следующую роль – scrum master. Как это ни парадоксально, успешность scrum во многом зависит от scrum мастера. Поэтому хочется снова призвать силу воображения и привести метафору (дисклеймер: пример никоим образом не должен оскорбить чьих-либо чувств). Есть культура, у которой есть свой культ, свои обряды, есть служители этого культа. Служителей можно разделить на различные классы:

• те, кто со своей культурой предпочитают быть один на один — отшельники, затворники, просветленные;
• те, кто выучили все правила, нашли лазейки, понимают, что и как делать, и используют культ в корыстных целях, наживаясь на людях, их страхах и предубеждениях;
• фанатики, которые пытаются насадить свою культуру к месту и не к месту. Для которых кроме их знаний, всё остальное ересь;
• те, кто искренне верит, чувствует и пытается поделиться, помочь и подарить это чудо людям; они рассказывают и объясняют, слушают и пытаются помочь.

Со Scrum и SM-ами, мне кажется, происходит очень похожая история. Попробуйте посмотреть на знакомых вам SM через такую призму. С какими SM вам бы хотелось работать?

Давайте разберемся, какие тревожные симптомы могут быть у SM.

Продуманная стратегия внутреннего общения — основа высокой продуктивности коллектива

Представьте себе типичное собрание всего коллектива: кто-то делает заметки и задает вопросы, кто-то опоздал и сидит, уткнувшись в телефон. Если при этом вы сами — руководитель, вам наверняка неприятно видеть экраны смартфонов, озаряющие лица сотрудников. Но если вы простой работник, и сообщаемая информация не имеет отношения к вашим повседневным обязанностям, ее проще игнорировать. Описанная ситуация — лишь один пример того, как может нарушиться общение внутри компании.

Внутреннее общение — это любая связанная с работой коммуникация, происходящая внутри организации: от всеобщих объявлений до разговоров между коллегами. Если видеть во внутреннем общении общекорпоративную стратегию, а не ответственность конкретного лица или отдела, это поможет организации устранить некоторые структурные проблемы и сформировать культуру доверия, прозрачности и сплоченности.

Джеймс Хартер и Эми Адкинс из Института Гэллапа в статье для Harvard Business Review пишут: «Часто общение составляет основу здоровых отношений, включая таковые между работником и руководителем. [Постоянное общение] — лично, по телефону или в электронном виде — связано с более высоким уровнем вовлеченности». А чем выше вовлеченность, тем лучше прибыли. В Институте недавно выяснили, что компании с высокой вовлеченностью сотрудников по дивидендам на акцию опережают конкурентов на 147%.

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

Переведено в Alconost

Дети, рожденные в год подписания Agile Manifesto, в этом году празднуют совершеннолетие. А взрослые люди продолжают спорить, где Agile применим. Обычно бьют по площадям: можно ли использовать Agile вне IT. Иногда добавляют драмы: пробовали ли вы строить атомную электростанцию по Agile? Для художественного эффекта так, конечно, лучше. Но если вы хотите сделать продукт, а не победить в конкурсе ораторов, то лучше смотреть применительно к конкретной ситуации.

В этой статье мы расскажем о нескольких моделях оценки применимости Agile и подробнее остановимся на одной их них — Agile Suitability Model, представленной в Agile Practice Guide от PMI и Agile Alliance.

Если вы озаботитесь хотя бы некоторыми полезными вещами:

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

то они улучшат рабочий климат в команде разработке.

Привет! Меня зовут Настя, я аналитик мобильного приложения Альфа-Бизнес. Иногда меня спрашивают о том, чем я занимаюсь на работе. Друзья, родные и, как это ни странно, разработчики. Каждый раз я отвечают по-разному, пытаясь привести наиболее близкие собеседнику примеры.

«Системный аналитик переводит требования пользователей с человеческого языка на разработческий…» — звучит довольно понятно для человека, не связанного с ИТ. Но если ты непосредственно участвуешь в разработке, вряд ли такого определения будет достаточно. Ради небольшого эксперимента я задала своей команде вопрос: «Чем занимается системный аналитик?». Читаем под катом, что из этого получилось.

Привет, Хабр! Меня зовут Леша, я системный аналитик одной из продуктовых команд Альфа-Банка. Сейчас я занимаюсь развитием нового интернет-банка для юридических лиц и индивидуальных предпринимателей.

А когда ты аналитик, тем более в подобном канале, без документации и плотной работы с ней — никуда. И документация — это та штука, к которой всегда возникает много вопросов. Почему веб-приложение не описано? Почему в спецификации указано, как должен работать сервис, а работает он вообще не так? Почему вообще спецификацию в состоянии понять только два человека, один из которых ее написал?



При этом игнорировать документацию нельзя по очевидным причинам. И чтобы упростить нам жизнь, мы решили провести оценку качества документации. Как именно мы это делали и к каким выводам пришли — под катом.

Как мне кажется, одна их самых больших проблем в скраме — это полный рассинхрон между людьми в команде. Мне пока не удавалось увидеть ни одного стабильного решения этой проблемы. Конечно, есть стандартные инструменты, но далеко не всегда они дают ответы на все вопросы и закрывают все дыры.

Предлагаю зайти к нам в гости и посмотреть как с проблемой синхронизации внутри себя борется команда “Онлайн-ипотеки” компании “Альфа-Банк”.

Преподаватели курса Project management in IT — менеджеры из «МегаФона», OneTwoTrip, Redmadrobot составили список книг на лето, которые пригодятся каждому проджекту. Узнайте, зачем современному менеджеру древний военный трактат, что общего между котами и разработчиками и где ошибались CEO General Motors и Zappos.

Первоначально я собирался написать статью о том, как правильно и эффективно организовать процесс разработки с использование Agile-методологий. Однако, посидев некоторое время над пустым окном редактора, я понял, что сам не знаю, как это сделать. И не потому, что это невозможно. Каждый проект уникален и нельзя создать общий рецепт, который будет работать везде и всегда. В тоже время, в процессе обдумывания статьи, мне вспомнилось несколько типичных ошибок внедрения гибких технологий, которые если и не уничтожат, то гарантированно подпортят результат. Поэтому, действуя согласно принципу от обратного, я решил написать про них.

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

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

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