Оценить:
 Рейтинг: 0

Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

Год написания книги
2022
Теги
<< 1 ... 11 12 13 14 15 16 17 18 19 ... 30 >>
На страницу:
15 из 30
Настройки чтения
Размер шрифта
Высота строк
Поля
Вот пример когнитивного искажения, которое называется «проклятие знания». Это когда человек более информированный не может рассмотреть проблему с точки зрения человека, который знает меньше. Отсюда столько непонятых гениев.

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

2.5.6. Эффект генерации

Не все когнитивные искажения – причина проблем и непонимания. Бывают и полезные. Например, «эффект генерации». Благодаря этому искажению человек лучше запоминает информацию, когда воспроизводит ее сам, а не воспринимает извне.

Это искажение используется в авиации. Например, когда диспетчер общается с пилотом. Если диспетчер на земле передал какую-то информацию, пилот в самолете должен повторить все параметры, которые были заданы. Менеджерам тоже полезно использовать этот прием, чтобы проверять, правильно ли подчиненные поняли задачу. Называется – «выписать квитанцию».

2.5.7. Слепое пятно

Еще одно когнитивное искажение: слепое пятно в отношении когнитивных искажений. Человек, который в курсе, что искажения существуют, отрицает их влияние на свое поведение. А последствия списывает на обстоятельства и на глупость окружающих. И, соответственно, не делает ничего, чтобы пофиксить свои когнитивные искажения.

Так что, если подчиненный говорит вам, что вы начитались книг по психологии, а задачу «Ну правда невозможно никак выполнить» – может быть, пора отдать задачу другому исполнителю.

2.6. Для тренировки

Выработка требовательности и уверенности, если вы не обладаете этими качествами, должна стать для вас приоритетным проектом.

Начинайте с выдачи небольших заданий, но добивайтесь по ним 100 % выполнения. Сначала ставьте задачи тем исполнителям, которых вы психологически сильнее. Опирайтесь на власть своего руководителя, правила компании, парадигмы, стандарты отрасли, регламенты. Затем – на здравый смысл и эстетику. Постепенно переходите к иррациональному уровню.

В течение недели следите за собой и за своими коллегами: подмечайте, какие неконкретные слова и выражения и в каких ситуациях они применяют. Когда вам, вроде бы, что-то ответили, но легче от этого не стало. Иными словами, отлавливайте отмазки: «не знаю», «я подумаю», «скоро» и так далее. Сюда же – три импотентских глагола: попробую, постараюсь, попытаюсь. «Попробую» с русского на менеджерский язык переводится – «отстань, я этого не смогу».

Составьте свой словарик таких слов и натренируйте слух, чтобы, как только эти слова прозвучат в вашем присутствии, у вас рефлекторно появлялось желание

попросить человека, как минимум, конкретизировать эти слова до сроков, цифр и конкретных артефактов.

И постарайтесь не перегнуть палку – уж больно хлопотно исправлять управленческие ошибки.

Литература

? Нассим Николас Талеб, «Рискуя собственной шкурой. Скрытая асимметрия повседневной жизни».

? Александр Фридман, «Вы или хаос. Профессиональное планирование для регулярного менеджмента».

? Александр Фридман, «Управление мышлением подчиненных: центрирующие парадигмы», аудиокнига.

? Павел Сивожелезов, «Сложные переговоры с подчиненными».

? Максим Дорофеев, «Джедайские техники» и «Путь джедая».

Пояснения

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

Архитектура – это общее устройство кода сайта или приложения: используемые библиотеки, модули, классы, функции и их отношения. Иными словами, общее описание, внутри которого разработчик пишет код. Вопрос об идеальной архитектуре философский, и многие разработчики стремятся к совершенству архитектуры как йоги к Нирване (зачастую, зря тратя время).

Большинство современных промышленных систем реализованы с использованием паттерна проектирования приложения MVC (Model View Controller) или его производных. Не все, это не догма, есть и альтернативные варианты, но этот подход чаще всего применяется. Model-View-Controller или MVC, или «Модель-Представление-Контроллер» – предполагает разделение данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента:

Модель (Model) предоставляет данные, как правило, лежащие на сервере, например, в базе. И эти данные со временем могут как-то модифицироваться. Например, на сервере хранится информация о товаре.

Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели. То есть, как этот товар показывается на странице.

Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.

Чтобы было понятнее, пример. В базе данных у вас лежит товар. Его можно вывести и на страницу с карточкой товара, и на страницу списка товара и в корзине пользователя. Физически в базе это будет один и тот же товар, но отображаться он будет по-разному. За хранение данных о товаре отвечает модель. За то, как этот товар можно показать пользователю – представление, или View, их может быть несколько. Ну и есть некие операции, которые можно выполнять с товаром: положить в корзину, удалить из корзины, удалить из базы, добавить остатки на складе и так далее. За них отвечает контроллер.

Понимание паттерна проектирования может быть важно, когда вы оцениваете проект: расписываете его по экранам и операциям с каждой сущностью данных.

Scrum – передовой фреймворк (платформа), созданный в 90-е специально для разработки, передачи и поддержки сложных продуктов. Сейчас используется и в других сферах. Суть: весь объем работы делится на короткие этапы в 2–4 недели (спринты), в рамках которых выполняется конкретный перечень задач из бэклога (списка всех задач, упорядоченных по приоритетности). Подробнее о Скраме мы поговорим в главе 3.

Карта компетенций – таблица со списком и уровнем необходимых навыков по каждому сотруднику. Благодаря ей можно оптимально распределять людей по командам, следить за прогрессом каждого из них и давать задачи на прокачку недостающих навыков. Подробнее о картах компетенций говорим в главе 7.11. Пример карты компетенций ищите в Приложении 1.

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

CSS-файл – каскадная таблица стилей, которая применяется для оформления веб-страниц. С помощью CSS-файла задается цвет, шрифт, положения отдельных блоков на странице.

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

Часть 3

Пятиминутный scrum

Настало время кратко посмотреть на Scrum – фреймворк разработки проектов. «Фреймворк» означает, что в чистом виде, по книге, у вас это вряд ли заработает. Ладно-ладно, заработает, но не с первого раза. Его нужно будет настраивать и сращивать с вашими текущими процессами.

Фреймворк уже зрелый: по нему много литературы, курсов и сертификаций. Поэтому здесь мы поговорим о нем коротко – только в той мере, в которой он нам нужен для повседневной, практической работы. Фреймворк не без косяков, с известной зоной действия и ограничениями. Но пока принципиально лучше ничего не придумали. И Scrum хорошо работает с удаленными командами.

3.1. Схема scrum. Артефакты. Роли. Процедуры

Итак, продукт выпускается поэтапно. Сначала минимальная версия. Затем постепенно наращиваем функциональность.

Каждый цикл разработки называется Спринтом. Рекомендованная продолжительность спринтов – от 1 до 4 недель, подбирается экспериментально. Нужен ритм «рывок-отдых». В итоге каждого спринта должна получиться новая версия продукта с приростом функций – инкрементом.

Product Owner (Владелец Продукта) отвечает башкой за стратегию и приоритеты разработки. К нему поступают «хотелки» пользователей, метрики, жалобы, баги, идеи стейкхолдеров. Коллективная ответственность в расстановке приоритетов не работает. Но рутину вроде сбора обратной связи можно делегировать.

В Scrum-е нет нудного толстого технического задания, которое выполняется от корки до корки. Нет попытки предусмотреть все и сразу. Вместо ТЗ хотелки складываются в специальную табличку – Product Backlog – и сортируются по приоритетам с точки зрения бизнеса. Можно по ходу работы менять, выкидывать и добавлять функции.

Примерно так это выглядит:

Простой бэклог в Google Docs

Минимальный состав бэклога: хотелка и приоритет. Можно добавлять свои поля. Например, описание и предварительная трудоемкость. Чаще всего, в условных единицах – Story Point. Берем за 1 балл самую простую хотелку, все остальные оцениваем относительно нее. Бэклоги удобно хранить в Google-таблицах. Можно дать доступ команде и синхронизировать с таск-трекером типа Jira.

Приоритет – чем больше число, тем выше. При ручной расстановке приоритетов удобно делать между ними зазоры (100, 200, 500). Так проще будет вставлять хотелку между двумя другими. Одинаковых приоритетов, по классике, быть не должно.

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

Все заинтересованные лица могут добавлять что-то в бэклог. Но только Product Owner определяет приоритеты. Для этого нужно периодически просматривать бэклог, выкидывать оттуда мусор, обновлять приоритеты и улучшать формулировки.

<< 1 ... 11 12 13 14 15 16 17 18 19 ... 30 >>
На страницу:
15 из 30