Владимир Бычко об управлении проектами

пиэм разъясняет, предостерегает, рекомендует

Месяц: Январь, 2023

Примеры тестовых заданий для менеджера проектов

Изображение с burst.shopify.com

Бытует мнение, что тестовое на пиэма составить невозможно. Также есть мнение, что делать их не нужно. Однако, пока у вас мало опыта и недостаточно крутое портфолио, тестовое даёт возможность показать настоящие знания работодателю.

Дальше будут вопросы и задания из моих реальных попыток трудоустройства за последние восемь лет. Большинство ссылок на файлы работодателя уже не работают, к сожалению.

* * *

  1. Исследовать, как на популярных сайтах и сервисах реализованы механизмы добавления контента в Избранное (Favorites). Рассмотреть процесс не с технической точки зрения, а с точки зрения удобства для пользователя.
  2. По результатам исследования подготовить краткий отчет о текущих тенденциях в процессе добавления контента в Избранное (Favorites). В отчете привести ссылки, скриншоты и краткие характеристики с точки зрения usability для каждого рассматриваемого сайта.
  3. Выбрать из проанализированных методов добавления контента в Избранное самый простой и удобный с точки зрения пользователя, обосновать выбор. Описать, как работает выбранный механизм в виде краткого описания всего процесса: что видит пользователь, какое поведение при добавлении в Избранное, при удалении из избранного, дополнительные подсказки, которые получает пользователь в данном процессе.

* * *

Вам нужно оценить проект, предполагающий как верстку, так и JS-программирование. Часть проекта уже реализована не в CSSSR, как вы будете действовать, чтобы учесть и минимизировать риски при оценке трудозатрат?

Наш заказчик — производитель воздушных шаров — готовит выставочный стенд. Частью стенда предполагается сделать HD-телевизор, чтобы демонстрировать на нём презентацию компании.

PR-директор заказчика обратился к нам с просьбой сверстать презентацию под нативный браузер этого телевизора.
А. Какие риски в реализации этого проекта вы видите?
Б. Предложите, как минимизировать риски.

Умение задавать правильные (исследовательские) вопросы, и последовательно добиваться четких, однозначных ответов — ключевой навык менеджера.
Взгляните на этот UI-kit (ссылка протухла). Сформулируйте список вопросов, ответы на которые помогут вам оценить трудозатраты по вёрстке и JS-программированию.Учитывайте, что тот, кто будет на них отвечать может и не обладать техническими познаниями в веб-разработке.

* * *

Оцените трудозатраты по вёрстке и JS-программированию этого UI-kit (ссылка протухла). Представьте, что вы уже получили ответы на все уточняющие вопросы из предыдущего задания. Закладывайте в оценку самый трудоемкий вариант. Составьте эстимейт в этом же файле, по шаблону приведенному ниже. Требования кроссбраузерности ограничиваются только самыми последними десктопными версиями Chrome, FireFox, Opera, Safari, IE.

Оценка сильно зависит от скиллов исполнителя. Берём «сферических верстальщика и джависта в вакууме»

* * *

Приведите в порядок этот договор (ссылка протухла), чтобы его было не стыдно отправить заказчику на согласование. Для этого сделайте копию документа в Google Docs.

* * *

Вы получили следующее ТЗ от заказчика для разработки web ПО: «Необходимо сделать кнопку, при нажатии на которую начинается салют». Составьте список уточняющих вопросов, которые Вы бы ему задали при обсуждении.

* * *

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

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

Есть три основные роли — посетитель, менеджер и старший смены.

* * *

Звонит заказчик. Он рассержен создавшейся ситуацией. Из разговора вы понимаете, что проблема заключается в том, что когда он вбивает в поисковую строку яндекса свой сайт, то видит в результатах выдачи сообщение: “Возможно, ваш сайт заражен вирусом, не рекомендуем переходить на него во избежание заражения…” Что вы ответите клиенту? Опишите пошагово свои действия. Проанализируйте и укажите, сроки выполнения задачи.

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

Вы работаете на должности аккаунт-менеджера. Одному из Ваших проектов требуется установить Google analytics. Вам нужно делегировать задачу или часть задачи вебмастеру. Ваши действия/ТЗ/Этапы?

* * *

Вводная: Представь, что твоей команде (5-7 человек) пришлось на неделю прервать работу над проектом (например, задерживается серверная разработка заказчика c API, тянут со стартом оплаты бухи или компонент, от которого вы зависите от других отделов).

Задача: Как ты построишь работу команды на этой неделе?

Вводная: Внутренний заказчик (в холдинге) сформулировал требования так: мне нужен проект к событию ЧМ-2018. Он может быть фановым мобильным приложением или игрофикационным, но важно прокатиться на этой волне и заработать денег. И это все требования которые он выставил.

Задача: Опиши твой алгоритм действий, декомпозицию оценки стоимости разработки проекта, 1-2 компонента/пользовательской роли для ТЗ (как раз важно будет понять, по какой структуре ты их готовить умеешь), и скоуп для первого спринта команды разработки.

* * *

Каким образом вы будете выявлять проблемные ситуации и возможности их решения на своей новой должности?

Какие бы вы задали вопросы нам, чтобы показать, что вы мыслите стратегически?

Какой алгоритм аудита проекта вы считаете правильным? Опишите его.

Представьте, что ваша команда вынуждена на неделю прервать работу над проектом (например, изменились бизнес-требования по проекту и заказчик попросил заморозить проект на неделю) Как вы построите работу команды на этой неделе? (Команда: аналитик, ведущий тестировщик, и джун тестировщик)

Есть рабочая коммуникация по следующей схеме Аналитик делает постановку => Тестировщик тестирует её => Тестировщик передает на разработку протестированную постановку => Разработчик передает готовое разработанное приложение тестеры на тестирование => Тестировщик находит много ошибок и возвращает приложение на доработку. Какой инструментарий вы бы применяли для оценки этого процесса? На каких “стыках” есть потенциальные опасности, поясните свою мысль? Что бы вы изменили в этом процессе?

* * *

От постоянного Клиента к нам пришел срочный заказ: «Сделать мобильное приложение наiOS/Android, которые бы использовали данные изPower BI».

Условия:

  1. Дедлайн — 1.5 календарных месяца, начиная с сегодняшнего дня.
  2. Предварительная оценка на мобильный проект 400 на каждую платформу, 300 бэкенд.
  3. Задачу сPower BIвыполняет сторонняя команда, но на нашей стороне необходимо готовить данные, предварительно это займет около 20 часов в неделю бэкенд разработчика.
  4. На стороне клиента: менеджер проекта (работает непосредственно с вами), руководитель отдела и генеральный директор. Менеджер (клиента) проекта должен утверждать части выполненных работ и готовый продукт с руководителем отдела. Готовый продукт всегда утверждается у генерального директора, по прошлому опыту на это уходит около одной недели.

CTOподготовил для вас: 1 бэкенд разработчик, 1iOSразработчик, 1Androidразработчик, 1QA+ обещание передать любых разработчиков в течение 2-х недель после запроса. Так же у вас есть дизайнер, готовый работать фултайм.

На получение фидбека отQAи исправление багов уходит 2 недели.

Менеджер процессов подготовил для вас:1 аналитик и разрешил подключать других менеджеров проектов, если они свободны. В вашем отделе работают три менеджера. Они могут выполнять любые роли от аналитика до скрам-мастера. Кстати, по ощущениям аналитика, у него уйдет около 10 рабочих дней на весь проект.

СЕО сообщил: «Проект важный и вы можете мотивировать разработчиков бонусами, не более 20% от заработной платы в месяц»

Аккаунтпросит вас описать правила работы с Клиентом, обещает их продавить и согласовать, так как у Клиента горят сроки, и они согласны на любые адекватные условия.

Опишите, пожалуйста:

  1. План А и План Б для разработки этого проекта простыми человеческими словами.
  2. Общие риски проекта и план, если риски срабатывают.
  3. Подготовьте упрощенные диаграммы Ганта для каждого плана, чтобы были видны все роли и общий таймлайн.

* * *

Часть 1

Уважаемый кандидат! В настоящем задании представлено краткое описание предполагаемой ситуации. Пожалуйста, проанализируйте её и ответьте на вопросы в письменном виде:

1. Что сделать менеджеру проекта?

2. Как ему избежать подобных проблем в будущем?

Описание предполагаемой ситуации

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

В команде работала пара технических лидеров – атомные ледоколы, которые, куда скажешь, туда и плывут. Настойчиво, целеустремленно и неутомимо. И было несколько стажеров и малоопытных специалистов.

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

Алексей, видя активность в работе специалиста, а также его отдачу в проекте, понимал, что надо парня двигать вперед. Но как это делать, Алексей не понимал. Точнее, не было времени. Новую функциональность надо было выпускать каждый месяц, а это требовало пристального внимания руководителя. Кроме этого, команда укладывалась в сроки только благодаря наработкам этого специалиста. Алексей понимал, что переведи он ценного специалиста на другой проект, он гарантированно не сможет обеспечить выполнение обязательств по уже заключенным компанией договорам с данным ключевым Заказчиком. «Но делать с парнем что-то надо, – думал Алексей, – рано или поздно ему все это надоест».

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

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

До встречи со специалистом, на которой Алексей должен был объявить ему о новой работе, оставался еще час. Нужно было что-то придумать.

Часть 2

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

Описание предполагаемой ситуации

Вы руководите проектом по разработке новой информационной системы, используя Scrum. В вашей команде 2 разработчика (Алексей и Михаил), аналитик (Елена) и тестировщик (Артем). Вам необходимо составить план работ на первую 2х недельную итерацию, основываясь на оценках, которые вам сообщает команда.

ЗадачаОценка от команды
Задача 1Алексей: в целом задача ясна и мне будет скорее всего достаточно 16 часов на ее реализацию, если не будет проблем. Елена: учитывай, что на уровне БД скорее всего буду проблемы с написание процедур Алексей: ну если так, то можно еще 7 часов добавить на решение возможных проблем, но это максимум. Скорее всего я все решу за 20 часов.
Задача 2Михаил: делал аналогичную задачу в прошлом проекте с тем же стеком. Хватило 7 часов на реализацию
Задача 3Елена: Тут сначала мне нужно спроектировать логику работы. Задача большая часов на 40. Да и нужно в процессе пообщаться будет с Михаилом, отвлечь его часов на 6. И не забывайте, что я буду в отпуске 2 дня где-то в середине выполнения данной задачи.
Задача 4Артем: мне на тестирование каждой выполненной задачи понадобится 2 дня. Это с учетом составления протокола

При составлении плана стоит учесть, что задачи 1 и 2 могут выполняться параллельно, а задача 3 может зависит от выполнения задачи 2.

Подумайте над рисками, которые бы вы заложили в план итерации.  Какие вопросы вы бы задали команде в реальной ситуации?

* * *

Вы поставили программисту задачу: «Заменить все ссылки на сайте — на фиолетовые». От программиста поступил ответ: «Мне кажется, фиолетовый — это цвет самоубийц. Поменял на серые. Так круче!».

  • Какие цели и интересы преследовал программист?
  • Какие цели и интересы у менеджера в данной ситуации?
  • Описать свои действия в такой ситуации, аргументировать их.

* * *

Зачем команде разработки нужен менеджер?

Кейс 1

Вы будете заниматься редизайном платформы IT-волонтёр. У вас в команде будет product owner, UX-дизайнер и три fullstack-разработчика. Команда распределённая. Основные цели редизайна:

  1. Повысить вовлечённость волонтёров
  2. Увеличить число решаемых задач
  3. Сделать дизайн более современным

Не позднее 20 апреля 2020 года должна быть выпущена новая версия сайта.

Вопросы:

  • Какие изменения сайта вы считаете ключевыми для достижения указанных целей? Что нужно сделать в первую очередь?
  • Предложите план работы.
  • Как вы построите коммуникацию в команде?
  • За месяц до дедлайна вы поняли, что не укладываетесь в срок. Что будете делать?
  • Как подготовиться к внедрению изменений?

Кейс 2

Вы будете развивать платформу Теплосеть (ссылка протухла). В этой команде будет product owner, UX-дизайнер, специалист по геймификации, fullstack-разработчик. Команда распределённая.

Вопросы:

  • Некоторые специалисты (дизайнер, геймификатор) будут заняты не только в этом проекте. Как вы будете договариваться о приоритете задач с коллегами из других проектов?
  • Как можно сбалансировать работу над продуктовым бэклогом и багами/техническим долгом?
  • Как провалидировать оценку сроков, данную разработчиком?

* * *

Вы вышли в логистическую компанию менеджером проекта на проект агрегатор курьеров. Менеджер продукта уже принял решение, что в начале надо делать регистрацию курьеров и просит вас подготовить требования для команды разработки. В разговоре он рассказал, что работаем только с курьерами с ИП и обязательно нужно собрать персональные данные (ФИО, паспорт, телефон и email). Т.к. рабочее место курьера — это мобильный телефон, то регистрация должна происходить там.

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

* * *

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

Вам необходимо:

  • Создать краткое ТЗ на создание сайта с функционалом регистрации 2 категорий пользователей (заказчик/исполнитель), чатом для обсуждения задачи и отметки о выполнении заказа заказчиком.
  • ТЗ должно содержать графическую часть (прототип 3-5 основных страниц), описательную часть (1 страницу)
  • Сделать описание декомпозиции и распределения задач между исполнителями/подрядчиками с учетом максимально сжатых сроков создания продукта.
  • Описать свои задачи во время производства и внедрения продукта.
  • Описать возможные риски по ходу разработки и способы решения проблемных задач.
  • Описать необходимые ресурсы для решения задачи.

Описывайте все кратко, нам необходимо понять ваше умение доносить информацию, знание процессов и имеющийся опыт.

* * *

Задание 1.

К вам пришел клиент с заказом на мобильное приложение.
У вас есть: разработчики ios/android, ba,qa,дизайнер и вы — руководитель проектов.
Задачи:

  • Спланировать разработку от старта до сдачи клиенту готового продукта.
  • Составить и защитить план проекта перед заказчиком.

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

Задание 2.

Дано:
Вы являетесь руководителем проектов со стороны профессиональной студии
мобильной разработки. На совещании внутри компании, руководитель портфеля
проектов сообщил Вам, что отдел продаж запросил с Вами встречу.

Придя на данную встречу, Вы узнаете со слов специалиста отдела продаж, что они
нашли проект на доработку. Цель доработки проекта — реализовать перечисление
чаевых при оплате через банковскую карту в клиентских приложениях. Также
специалист по продажам упомянул про то, что есть готовое API, а исходники проектов
под NDA. Все эти материалы были направлены вам после встречи.

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

Вечером у Вас было совещание с портфельным руководителем.

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

Задание: Проведите все необходимые мероприятия по анализу и планированию
проекта от начала до сдачи клиенту. Финальные документы необходимо защитить
перед руководителем портфеля проектов. Он дал на выполнение задания 1-2 недели.
В компании процессы управления проектов проходят в соответствии со стандартами
PMBok, поэтому вам рекомендуется выполнять тестовое задание учитывая этот
стандарт.

* * *

Задание №1

Покупатель купил яблоки по цене $a и груши по цене $b потратив ровно $c (a, b, c вводится пользователем).

Создать блок-схему программы, которая методом перебора найдет сколько яблок и сколько груш купил покупатель.
Блок схема должна быть представлена в формате UML Activity.

Задание №2

В Microsoft Excel есть три колонки Date; Project; Hours spent.
Посчитайте формулой по каждому дню и каждому проекту сумму Hours spent. Выведите формулой уникальные значения по колонке Project.
Посчитайте формулой сумму Hours spent по каждому проекту за все дни.

Microsoft Excel

Вам необходимо скачать файл “Тестовое задание на знание Excel” и переслать его обратно с готовым решением.

* * *

Кейс #1

Команда работает по двухнедельным спринтам. По окончанию итерации происходит релиз.

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

Как следует поступить с текущим спринтом?

Как предусмотреть возникновение аналогичной ситуации в будущем? В рамках каких событий и с кем будет происходить поиск решения?

Существуют ли критерии готовности историй для релиза? Какие? Кто их генерирует? Кто контролирует и принимает решение о готовности спринта к релизу?

Кейс #2

Для Data Science команды опишите процесс работы с гипотезами данных, этапы процесса, критерии прохождения каждого этапа.

Кейс #3

Приведите примеры метрик, которые описывают эффективность процесса разработки. Для 1-2 метрик опишите, как их можно измерять и с помощью каких инструментов

Кейс#4

Опишите отличия методологии Скрам от методологии Канбан. Как выбрать более подходящую для команды методологию?

Что менеджеру проектов нужно знать об API

Изображение с unsplash.com, автор Rubaitul Azad

В изрядной доле проектов нужно интегрировать два или больше приложений. В самом тривиальном случае — фронтенд с бэкендом. В более сложном — мобильное приложение с бэкендом. В случае со звёздочкой — два бэкенда и другие извращения. Стандартом де-факто для таких задач в наше время считается API.

Кроме того, в вашем продукте может потребоваться реализовать дорогостоящую функцию, которая уже сделана в стороннем сервисе на отличненько. Например, если вам нужны карты, целесообразно использовать API Open Street Map или Яндекс.Карт, это сильно дешевле, чем пилить собственные карты.

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

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

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

Самая прозрачная аналогия с реальным миром — ресторан. Кухня — бэк, зал ресторана — фронт, официанты — API. Посетитель через зал посетителей стучится в API-официанта, даёт ему заказ. Официант доставляет заказ кухне-бэкенду, там его готовят и отдают официанту, который доставляет результат клиенту в зал ресторана. Если всё сильно упростить, реальное API работает именно так.

Различия REST и SOAP

Чаще всего в современной разработке встречаются REST и SOAP API. Давайте разберём, в чём разница.

REST

REST (от англ. Representational State Transfer — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети.

Предполагает использование протокола HTTP для передачи данных.

Применяется преимущественно в вебе и в мобильных приложениях.

Ещё используется в облачных вычислениях.

Через REST API могут передаваться разные форматы данных, но обычно используется JSON.

Предполагает кэширование передаваемых данных.

Хорошо масштабируется.

SOAP

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC).

При помощи SOAP данные могут передаваться не только через HTTP, но и, например, MQ.

Применяется, преимущественно, в Enterprise, для интеграции нескольких отдельно стоящих систем.

Данные передаются только в формате XML.

Данные не кэшируются.

Типы запросов

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

  1. GET
  2. POST
  3. PUT
  4. PATCH
  5. DELETE

GET – используется для получения со стороны севера определенного ресурса. Если вы производите этот запрос, сервер ищет информацию и отправляет ее вам назад. По сути, он производит операцию чтения на сервере. Дефолтный тип запросов.

POST – нужен для создания определенного ресурса на сервере. Сервер создает в базе данных новую сущность и оповещает вас, был ли процесс создания успешным. По сути, это операция создания.

PUT и PATCH – используются для обновления определенной информации на сервере. В таком случае сервер просто изменяет информацию существующих сущностей в базе данных и оповещает об успехе выполнения операции.

DELETE – как и следует из названия, удаляет указанную сущность из базы или сигнализирует об ошибке, если такой сущности в базе не было.

Postman

Для тестирования API применяется инструмент Postman. Раньше он был плагином для Хрома, но сейчас это автономное приложение для любых платформ. Штуковина достаточно понятная интуитивно, разработчики чаще всего передают данные об API тестировщикам именно в виде коллекций Постман.

Есть публичное API для смешных переводов, например, эндопоинт для перевода на язык Мастера Йоды находится по адресу: https://api.funtranslations.com/translate/yoda.json

Эндпоинт принимает только один строковый параметр text. Отправим Постманом GET запрос на этот эндпоинт:

Интерфейс Postman с простым GET-запросом к API
Интерфейс Postman с простым GET-запросом к API

Как видите, API возвращает такой ответ:

{
    "success": {
        "total": 1
    },
    "contents": {
        "translated": "Force be with you yoda,Polovec helloy you",
        "text": "Hello Yoda, Polovec helloy you",
        "translation": "yoda"
    }
}

Как нетрудно понять, эндоинт возвратил код успеха, а в поле контента передал три значения:

  • translated — переведённый текст.
  • text — исходный текст.
  • translation — тип переводчика.

По такому же принципу работают любые REST API, только в реальных запросах параметров больше и они сложнее.

Применение в реальной разработке

Проектирует API обычно архитектор. Бэкенд-разработчики реализуют эндпоинты и пишут документацию. Фронтендеры или мобильные разработчики интегрируются с этим API, реализуют получение данных из него и отправку данных в него. Тестеры всё это проверяют.

Может сложиться так, что проект будет совсем маленьким и проектирование API поручат вам. Для такого случая предлагаю вам пример API спроектированного мной для мобильного приложения для операций с топливом.

Разное

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

Если вы интегрируетесь со сторонней системой и успех проекта сильно зависит от её корректной работы, попросите QA реализовать пинговалку стороннего API, они умеют это делать, в том числе с помощью Постмана. Система будет с определённой периодичностью слать запросы на внешнее API и если ответы перестанут поступать, будет записывать такие события в лог, с помощью которого вы потом сможете доказать, что разработка тормозила из-за отваливающегося стороннего API.

В целом, это всё, что пиэму нужно знать об API.

Манифест прожект менеджера

В Манифесте:

  • Методологии человеческим языком
  • Арсенал инструментов PM
  • Технические и продуктовые нюансы
  • Метрики
  • Рекомендации по созданию культуры в команде
  • Про CI/CD
  • Шаблоны
  • Вопросы к собеседованиям и т. д.

За документ спасибо Александру Коновалову.

SMART и самая важная буква в этой аббревиатуре

Изображение с unsplash.com, автор CDC

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

Мне кажется, что одна буква из этой аббревиатуры сильно важнее остальных. Но сначала давайте разберём их все.

Конкретная (specific)

С этим свойством целей я вплотную столкнулся, работая в одной мобильнокодерской компании. PMO меня спрашивает, что будешь делать сегодня для вхождения в проект? Я говорю, почитаю написанную до меня документацию. А он отвечает, что эта цель неконкретная и так формулировать нельзя. Конкретность — это прочитать документы А, B, C, составить список вопросов по ним.

Измеримая (measurable)

Если процессы и результаты не измеряются, процессов и результатов нет, однозначно. «Повысить продажи чапельников» — плохая цель. «Повысить продажи чапельников на 14,5 %» — уже получше.

Достижимая (attainable)

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

Значимая (relevant)

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

Ограниченная во времени (time-bound)

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

А теперь главная мысль этого поста. Самая важная буква в аббревиатуре SMART — R. Значимая. В мире делаются сотни незначимых проектов, которые на самом деле, не нужны заказчику, а пиэм делает их только ради пункта в портфолио. На рынок в результате выходят чудовищные продукты, дающие отвратительный пользовательский опыт и плохо решающие их проблемы, даже если все остальные буквы аббревиатуры учтены при постановке целей.

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

Использование аэропорта

Изображение с burst.shopify.com

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

Про ручную кладь

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

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

Что можно везти, а что нельзя

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

Баллончик с CS нельзя везти вообще.

В большинство стран вы можете везти тактическую ручку, только рядом положите одну обычную. В Голландию и Германию тактическую ручку нельзя, но я пишу о внутренних перелётах.

В правилах авиакомпаний обычно пишут, что психотропные таблетки можно везти только с рецептом. Полный идиотизм, потому что этот рецепт при покупке таблеток аптека изымает. На деле, четыре-шесть таблеток антидепрессантов вполне можно провезти, положив на дно сумки.

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

Антисептик в виде геля везти можно. В тот же пакет его положите.

Маленькую пустую пластиковую бутылку можете взять. Потом напишу, зачем.

Можете взять электрический тройник. Потом напишу, зачем.

Первичный досмотр

На входе в общий зал аэропорта нужно пройти досмотр. Берёте пластиковую лоханку и складываете в неё весь металл. Часы и ремень можно не снимать, просто покажете их сотруднику. Я, так как таскаю в карманах много предметов, просто снимаю куртку и пиджак, туда же кидаю кошелёк и ключи, после чего прохожу. В Шереметьево требуют снять шапку.

Общий зал аэропорта

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

Регистрация

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

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

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

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

Полноценный досмотр

Проследовав в направлении, которое укажет вам сотрудник, вы найдёте другого сотрудника, которому нужно показать паспорт и посадочный, он поставит туда штамп и вы пройдёте на досмотр.

Этот досмотр уже более серьёзный. Кладёте в лоханку верхнюю одежду, весь металл, снимаете ремень и часы. Могут потребовать снять ботинки (особенно если вы мамкин неформал и они у вас окованы металлом), в этом случае где-то рядом должен быть ящик с бахилами. Кладёте лоханку на ленту, она ползёт на рентген. Вы проходите через рамку и если ничего не пискнет, вас пропустят. Если пискнет, досмотрят ручной пикалкой и заставят выложить невыложенное.

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

Внимание. Если вы через Шереметьево провозите ноутбук, вас заставят его включить, видимо, чтобы вы не провезли под видом компьютера бомбу. Логиниться не надо, достаточно открыть экран и показать окно ввода пароля. Поэтому имейте в виду, что ноутбук должен быть заряжен, хотя бы чуть-чуть.

Зал ожидания

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

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

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

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

Посадка

После того, как встанете в очередь на посадку, приготовьте паспорт и посадочный. «Победа» смотрит и то, и другое, «Смартавиа» смотрит только посадочный. Очередь после начала посадки движется довольно быстро. Сотрудник заберёт ваш посадочный, вернёт от него корешок, который имеет смысл сохранить до конца поездки.

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

Через автобус всё несколько сложнее. Всю толпу посадят в автобус, иногда в один, иногда в два и повезут через весь аэродром к самолёту. Недалеко от самолёта высадят и вы пешком подниметесь по трапу в салон.

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

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

Ремень безопасности интуитивно понятен.

Стюардессы покажут, как пользоваться аварийной техникой, вроде спасательных жилетов.

Полёт

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

Через некоторое время после взлёта вам объявят, что самолёт перешёл в горизонтальный полёт и можно немного расслабиться. Можно расстегнуть ремни, опустить откидной столик, если очень повезёт, будет достаточно места, чтобы поработать за ноутом. Потом будут развозить нямку тем, кто её заказал при покупке билетов. Обычно можно купить какой-нибудь напиток или сэндвич. Вода чаще всего бесплатная.

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

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

Высадка

Иногда высадка производится в рукав, иногда в автобус. Колхозного варианта в крупных аэропортах ещё ни разу не встречал.

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

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

В международные рейсы я не летал ни разу, поэтому о них рассказать пока не могу.

Исследование зарплат руководителей проектов в 2022 г.

Сколько зарабатывали менеджеры проектов различных профилей в 2022 году. За исследование спасибо Артёму Летюшеву.

Бытовая типографика

Изображение с burst.shopify.com

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

Первое, что нужно сделать, заменить свою клавиатурную раскладку на раскладку Бирмана.

Раскладка Бирмана для мака.

Эта раскладка есть для винды и мака. Я буду писать о маке. На сайте написано, как их установить. Если вы пишете, в основном, на русском, русской раскладки будет достаточно. С английской всё несколько сложнее, потому что из макоси выпилить дефолтную английскую по-моему, невозможно. Если возможно, напишите в комментах, как.

На Вентуре у вас может возникнуть проблема с автоматическим переключением на русскую раскладку при помощи Пунто Свитчера. Макось при каждом таком переключении пишет, что произошла попытка переключения на несистемную раскладку. Решения для Пунто я так и не нашёл и перешёл на платную Карамба Свитчер и доволен как слон, потому что Карамба, кроме переключения раскладки, умеет ещё и в исправление опечаток, а ещё у неё отзывчивый создатель, который оперативно реагирует на письма пользователей.

Ладно, ближе к делу. При помощи раскладки Бирмана вам нужно освоить, как набирать следующие символы и научиться делать это на автомате:

«» „“

Русские кавычки. Это легко, они ставятся Option+ левая и правая угловая скобка. Если вам нужно набрать кавычки внутри кавычек, например: «Пакетированный чай ценится в тундре больше, чем „Хеннеси“. В приютившем меня стойбище, уважали „Липтон“», надо научиться ставить лапки. Это тоже легко. В фильме «Люди в чёрном» были агенты Джей и Кей. Нижняя лапка ставится Option+J, верхняя Option+K. Уже после того, как вы научитесь этому приёму, ваши тексты станут выглядеть круче.

Длинное тире. Есть дефис, минус, среднее тире и тире. Дефис ставится в словах, вроде «кисло-сладкий соус». Набирается обычной клавишей с дефисом. Тире ставится между отдельными словами, например «Встретил коллаборациониста — убей». Набирается Option+дефис. С минусом и средним тире можете не заморачиваться, это уже для совсем уж хардкорных пользователей. Правильное тире даст вашим текстам ещё сто очков.

Многоточие нужно уметь уместно применять в фразах с недосказанностью. Некоторые психи набирают четыре-шесть обычных точек. Обычные люди ставят три точки… А крутые чуваки ставят отдельный символ многоточия… В раскладке Бирмана набирается Option+слеш. Клавиша, слева от правого шифта.

© ™

Знаки копирайта и зарегистрированной торговой марки. Только ламеры пишут (c) и TM. Правильные чуваки жмут Option+С и Option+T для ввода этих символов.

←→

Стрелочки. Пригождаются, когда вы перечисляете действия. Например: «Chrome → Настройки → Автозаполнение». Левая стрелка нужна реже. Набираются Option+9 и Option+0

Знак рубля. Вводится Option+ русская Р. Тоже легко запомнить.

Всё. Остальные спецсимволы встречаются сильно реже.

 

Теперь поговорим о типографских приёмах для оформления текста.

1.

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

2.

Двойные пробелы. Я не знаю, откуда берётся привычка ставить их. Некоторые пользователи пишущих машинок делают это по привычке, откуда такое поведение у пользователей, эти машинки не заставших, мне непонятно. Текстовые редакторы обычно умеют в поиск и автозамену текста, запустите замену двух пробелов на один, выполните несколько раз. В браузере можно нажать Command+F и ввести в строку поиска два пробела, браузер подсветит двойные пробелы.

3.

Курсив и полужирное начертание. Запоминаем, курсив применяется, когда вам нужно обратить внимание пользователя на слово или фразу. Смысловой акцент. Достоинство курсива в том, что он не меняет визуальной плотности полосы. Полужирное начертание применяется там, где вам нужно озаглавить структурную часть текста, но заголовок для этого не подходит или ваше средство постинга не поддерживает заголовки вообще. Меняет плотность полосы. Важно. Выделить всё — не выделить ничего. При выделении полужирным и курсивом, если к слову прилеплен знак препинания, он тоже выделяется.

4.

Гиперссылки. Раньше в конце гиперссылок нельзя было ставить точки, потому что браузер принимал эту точку за часть гиперссылки и не открывал нужную страницу. Современные браузеры умеют не учитывать эти точки, но я по привычке после гиперссылок точку не ставлю. Важно. Если слово, содержащее гиперссылку в кавычках, кавычки не должны быть частью ссылки. Например: Текстовый редактор “Optima”. Или: Образовательная антинаркотическая программа «Школа — территория здорового образа жизни». Не делайте так: «Питерский трамвайчик — один из старейших сайтов с приколами. Тыц». Приклейте гиперссылку либо к «Питерский трамвайчик», либо «сайтов с приколами».

5.

Пробелы в тексте. После знака препинания пробел ставится всегда. В частности, если вы пишете фамилию и инициалы, например В. А. Зеленский, отделяете инициалы пробелом. Будет здорово, если вы примените неразрывный пробел, чтобы инициалы не оторвало от фамилии при переносе на новую строку. Ставится Option+Пробел. Также пробел ставится после точки-сокращения, например: г. Калиниград, Ганзейский пер., д. 4, кв. 2. Кроме того, тире всегда отделяется пробелами с обеих сторон, дефис никогда. Пробел ставится после знака номера, например: № 404. Хотелось бы, чтобы он тоже был неразрывным. По какой-то причине какие-то люди ставят пробелы в начале абзаца, имитируя красную строку. Так делать не надо, эти пробелы надо удалять. Если вы составляете документ в текстовом процессоре и красная строка — часть редакционной политики, делайте её средствами процессора.

6.

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

7.

Логины и пароли. Если есть возможность, примените к текстам логинов и паролей моноширинный шрифт. Никогда не знаешь, какой дефолтный шрифт у вашего читателя. Когда устраивался на последнюю работу, мне выдали пароль на обычной бумажке и я не мог понять, там g или q. Не надо так.

8.

Время. В российской типографике минуты отделяются от часов двоеточием. 12:30, но никак не 12-30 и точно не 12.30

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

Краткое руководство менеджера проектов в IT

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

Функциональное управление

Изображение с insplash.com, автор Barth Bailey

Ранее я писал о пирамиде принятия решений. Сегодня хотелось бы поговорить об отличиях функционального уровня управления от операционного.

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

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

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

Работа функционального менеджера уже не подразумевает доступа к каждому исполнителю, потому что их может быть от пятидесяти до ста в разных компаниях. Да, сохраняется доступ к непосредственным подчинённым. В грамотной системе ими должны стать как раз, операционные руководители — тимлид, ведущий аналитик, qa-лид. Но фигуры по доске двигать больше не надо. Надо создавать систему и оттачивать её работу.

Качество системы определяется двумя параметрами:

  1. Предсказуемость выдаваемых результатов.
  2. Способность к самостоятельной работе.

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

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

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

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

1

Нужность дедлайнов

Когда нужен дедлайн.
Изображение с unsplash.com, автор Towfiqu barbhuiya

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

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

Есть три основных аспекта, которые сильно влияют на нужность дедлайна.

Творчество и НИОКР

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

Изменчивость среды

Также имеет значение, изменчива ли среда, в которой делается задача. Меняется среда — меняются параметры задачи, едут сроки. Поэтому в постоянно изменяющихся условиях от жёстких дедлайнов мало толку. Готовность к изменениям важнее следования плану.

Состояние процессов

Имеет большое значение, расписаны ли отдельные подпроцессы, из которых состоит задача. Сколько-нибудь точное прогнозирование дедлайна работает только в условиях ясных процессов. Зато у задач с непрописанными процессами больший потенциал для оптимизации, нужно только в неё погрузиться и понять, что делается неэффективно.


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

Для себя отмечаю, что с задачами без дедлайна справляюсь быстрее. Логика такая — всё равно, когда сделать задачу, никто не торопит. Почему бы не сделать её сейчас? А если есть дедлайн, думаю так — до дедлайна есть ещё время, отложу ещё на один день, сделаю потом. Но такое мышление скорее исключение, в целом люди с задачами с дедлайнами справляются быстрее.