​​Один из топовых вопросов, который мне задают: «Что входит в обязанности менеджера?»

Я об этом уже писала раньше, но вчера вспомнила, что еще в 2014 году в России написали профессиональные стандарты, которые утверждены Министерством труда!

Профстандарт «Руководителя проектов в области информационных технологий» - https://goo.gl/eUiCKJ

и «Менеджера продуктов в области информационных технологий» - https://goo.gl/24S4Fp

Это не слишком простое чтение :)

#project #product
@projectsproducts

Нашла классное видео на Ted «How too many rules at work keep you from getting things done».
Yves Morieux рассказывает о продуктивности, мотивации и KPI проводя аналогию с эстафетой.

Ссылка на видео - https://www.ted.com/talks/yves_morieux_how_too_many_rules_at_work_keep_you_from_getting_things_done#t-22264

Немного цитат:
«Мы постоянно пытаемся переложить ответственность в чужие руки.
Кто ответственен за этот процесс? Нам надо, чтобы кто-то отвечал за конкретный процесс.

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


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

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

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

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

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


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

#project #product
@projectsproducts

Второе видео на Ted от этого же лектора Yves Morieux.
«As work gets more complex, 6 rules to simplify».

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

Ссылка на лекцию - https://www.ted.com/talks/yves_morieux_as_work_gets_more_complex_6_rules_to_simplify

«Давайте рассмотрим пример. Автомобильная компания, машиностроительное подразделение — представляет собой пятимерную матрицу. Если открыть любую ячейку этой матрицы, вы увидите другую 20-мерную матрицу.

У нас есть Мистер Шум, Мистер Расход горючего, Мистер Антиколлизионные Свойства.
Для каждой новой потребности существует специально выделенная должность, отвечающая за выстраивание линии работы инженеров адекватно этому новому требованию.

Что происходит, когда возникает новое требование?

Несколько лет назад новое требование возникло на рынке: продолжительность гарантийного срока.
То есть новое требование — ремонтопригодность, насколько легко ремонтировать тот или иной автомобиль.

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

Так какое решение предлагает нам жёсткий подход?

Если ремонтопригодность — это новое требование, решением является создание новой должности, Мистер Ремонтопригодность.

Мистер Ремонтопригодность создаёт процесс ремонтопригодности. С системой показателей, матрицей, и, в конечном счёте, стимулом ремонтопригодности. Это сверх других 25 ключевых показателей эффективности.»


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

Это не схема из прямоугольников, это нервная система, состоящая из способности к приспособлению и уровня интеллекта.»


«В банках, если существует проблема между бэк-офисом и фронт-офисом, то они не взаимодействуют. Каково решение?

Создаётся мидл-офис. Что происходит год спустя?

Вместо одной проблемы между бэк- и фронт-офисами, теперь у меня есть две проблемы. Между бэк-офисом и мидл и между мидл- и фронт-офисами. Плюс ко всему, мне нужно платить мидл-офису.»


«Глядите, дома у меня два телевизора. Почему?
Очевидно, для того, чтобы не сотрудничать с моей женой. Для того, чтобы не идти на компромиссы с моей женой. И я пытаюсь не идти на компромиссы с моей женой, именно потому что я люблю её.

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


«Генеральный директор группы LEG Йорген Виг Кнудсторп говорит, что нужно наказывать не за неудачу, а за отказ помочь или обратиться за помощью. Это полностью меняет дело. Внезапно в моих интересах становится честно говорить о моих слабостях, прогнозах, поскольку я знаю, что меня осудят не в случае неудачи, а если я не смогу помочь или попросить о помощи.»


#project #product
@projectsproducts

А вот в копилку про метрики статья от Анны Булдаковой «Как выбрать правильные метрики для продукта», если вы ее еще не читали, то посмотрите.

Ссылка - https://goo.gl/c1RsJi

#project #product
@projectsproducts

Продолжаем тему оценки проектов...

1. Параметрическая оценка

Параметрическая оценка применяется на ранних этапах проекта (на стадии определения проекта и на начальных стадиях проектирования), когда еще нет достаточного количества информации.

Сначала выбираются параметры оцениваемого проекта, которые изменяются пропорционально стоимости проекта.

А потом строится математическая модель.

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

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

Преимущество метода:
для оценки стоимости проекта достаточно знать "ставки" привлекаемых ресурсов.

Недостаток:
низкая точность (-30%-+50%).

Стоимость подготовки параметрической оценки:
0,04%-0,45% от общей стоимости проекта.

#project #foundation
@projectsproducts

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

Недавно я работала над проектом по масштабному обновлению интерфейса системы.

Это была гигантская задача.

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

Мы разбили проект на этапы: брали один кусок системы, меняли его, переписать, выкладывали, давали людям уже этим пользоваться.

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

#project #foundation
@projectsproducts

2. Экспертная оценка

Методы получения экспертной оценки:

- на основе индивидуального мнения:
берём мнения отдельных экспертов, независимых друг от друга.

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

- коллективные оценки:
основаны на использовании коллективного мнения экспертов.

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

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

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

Важно подбирать экспертов в соответствии с их компетентностью!

Если вы хотите подробнее почитать про эту тему, есть целое учебное пособие «ЭКСПЕРТНЫЕ ОЦЕНКИ» (автор А.И.Орлов), но это будет полезно для масштабных глобальных прогнозов, а не для IT проекта на 2 месяца.

#project #foundation
@projectsproducts

Оценка проектов.

3. Методика по аналогии

В этом варианте оценки нужно сравнить текущий проект с фактически потраченными человеко-часами на подобном проекте в прошлом, но не с изначально предполагаемым объемом!

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

Основными шагами тут будут:
- найти возможные аналогии, выделить подобные задачи,
- учесть фактор сложности, который должен быть определен и умножен на человеко-часы.

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

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

Тогда вы понимаете, что сложность при строительстве этого дома будет несколько выше.
Да ещё может быть ваш новый участок земли на склоне?!

#project #foundation
@projectsproducts

Одна из книг про оценку «Software Estimation: Demystifying the Black Art» (Steven C. McConnell).

Если не хотите целую книгу читать, то есть конспект по ней: http://igorshevchenko.ru/blog/entries/software-estimation

#project #book
@projectsproducts

​​Некоторые считают, что оценка проектов не нужна.

Но мое мнение:
если вы не тратите на это много времени, то от оценки много пользы.

#project
@projectsproducts

Заметка из книги “Руководство Джоэла Спольски по подбору программистов и управлению ими“.

Закон Брукса (Прим. из книги Ф. Брукса «Мифический человеко-месяц»), гласит: «Подключение к запаздывающему программному проекту дополнительных работников делает его еще более запаздывающим».

И вот почему:

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

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

#book #project
@projectsproducts

Про правильный найм сотрудников

Как это делали в Fog Creek Software (из книги “Руководство Джоэла Спольски по подбору программистов и управлению ими“):

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

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

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

Обычно после нашего просеивания в этой стопке оставалось примерно 10 заявлений (на одну вакансию), и мы приглашали тех, кто их прислал, на телефонное собеседование. В результате этого собеседования мы, скорее всего, пригласим двух"трех человек лететь в Нью-Йорк уже для личного собеседования.

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

Приглашенных встречает в аэропорту водитель лимузина, одетый в униформу. Погрузив их багаж, он быстро везет гостей в отель, вероятно, самый крутой из тех, что они когда-либо видели. Этот отель находится в районе модных магазинов. В него все время то входят, то выходят фотомодели, а сложные аксессуары ванной комнаты, вероятно, взяты из постоянной коллекции Музея современного искусства, но будет большой удачей, если вы угадаете, как ими чистить зубы. Дождавшись гостей в номере отеля, мы оставляем им подарочный
пакет с тенниской, предлагаем пешеходную экскурсию по Нью-Йорку, подготовленную штатными сотрудниками Fog Creek, а также DVD с документальным фильмом об участниках летней интернатуры 2005 года. В номере находится DVD-плейер, и многие из гостей могут посмотреть, как “прикольно” было предыдущим интернам.

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

Даже те, кому не повезло, возвращаются назад в студенческий городок, думая, что компания Fog Creek — классный работодатель, и рассказывая всем своим друзьям, как было прикольно остановиться в роскошном отеле в городе “Большого яблока”; это заставит их следующим летом написать заявление в интернатуру — хотя бы для того, чтобы иметь шанс на путешествие.

#book #project
@projectsproducts

Руководство к проведению собеседования
(продолжение из книги “Руководство Джоэла Спольски по подбору программистов и управлению ими“)

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

Часть вторая — это вопрос об одном из недавних проектов, над которыми работал кандидат.

Задавайте вопросы, допускающие разные толкования, после чего сидите и слушайте, только время от времени говоря: “Расскажите об этом поподробнее”, — на тот случай, если кажется, что кандидат вот"вот застопорится.

Что надо искать с помощью вопросов, допускающих различные толкования?

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

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

В-третьих, если проект, о котором рассказывают кандидаты, был коллективным, старайтесь узнать, брали ли они на себя руководство. Кандидат может сказать: “Мы работали над X, но начальник сказал Y, а клиент сказал Z”. Тут я спрашиваю: “И что же сделали вы?” Подходящий ответ на это может быть таким: “Я
встретился с другими людьми, занятыми в проекте, и написал предложение...”. А вот один из неподходящих ответов: “Ну, сделать я ничего не мог. Такая была ситуация”.

Помните: Будь способным и Доводи дело до конца.

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

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

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


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

Кто-то из тех, кто проводит собеседования, стараются определить, задает ли кандидат “интеллектуальные” вопросы.

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

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

#book #project
@projectsproducts

Правила проведения встреч

https://www.ted.com/talks/david_grady_how_to_save_the_world_or_at_least_yourself_from_bad_meetings?referrer=playlist-work_smarter

“Каждый день мы позволяем свои коллегам, которые во всем остальном очень, очень милые люди, воровать у нас.
И я говорю о чем-то значительно более ценном, чем офисная мебель.
Я говорю о времени. Вашем времени.
На самом деле, я верю, что мы в центре глобальной эпидемии ужасной новой болезни, известной как СБС: Синдром Бездумного Согласия. (MAS. Mindless Accept Syndrome)”

То самое видео, которое Дэвид показывал в своем выступлении:
https://www.youtube.com/watch?v=zbJAJEtNUX0

#project #product
@projectsproducts

Про разработчиков. (цитата Джоэла Спольски)

ОТНОСИТЕСЬ К НИМ, КАК К САМУРАЯМ

В знаменитом фильме Акиры Куросавы “Семь самураев” крохотная, обедневшая деревня, страдающая от постоянных бандитских набегов, пытается нанять семь самураев, чтобы те помогли ее жителям защищаться.

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

Этой деревней является ваша команда.

Самураи — это программисты, которые, как вы надеетесь, придут решить ваши проблемы, принеся свой талант и опыт в обмен, может быть, на миску риса.

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

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

Уделяйте очень и очень большое внимание деталям всего процесса рекрутинга, проведения собеседований и найма, чтобы исключить из него какую-то случайную деталь, которая посылала бы вашим кандидатам-звездам единственное сообщение: “Вы не достойны!”

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

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

И наконец, если вы кому-то должны сказать “нет”, то делайте это быстро и с уважением.

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

#book #project
@projectsproducts

Как бесполезные встречи крадут наше время

9 из 10 человек спят на встречах!
и это не шутка, знаю личные примеры :)

#project #product
@projectsproducts

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

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

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

#project #product
@projectsproducts

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

- Инкремент — это сумма завершенных во время Спринта Элементов Бэклога Продукта и всех инкрементов предыдущих Спринтов.

Полный текст руководства: https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Russian.pdf

#project #product
@projectsproducts

Стендапы. Зачем нужны и как проводить?

Есть очень подробная статья “It's Not Just Standing Up” от Agile коуча в Spotify про особенности и секреты утренних встреч команд, которые любят Agile.

- С какой песни нужно начинать стендап? (Ответ: Bob Marley’s “Get Up Stand Up”)
- Сколько должна длиться эта встреча? (Ответ: 15 минут или меньше)
- Как сделать так, чтобы эти 15 минут не были просто “выброшенными на ветер”? (В статье много советов и шаблонов для проведения)
- Про что говорить? (Ответ: “Yesterday Today Obstacles“)
- Вообще зачем? (Ответ: чтобы понимать, что вы команда; общее понимание целей, общая синхронизация и координация, рассказ о проблемах и решениях; шеринг знаний)

Подробные ответы на эти вопросы тут:
https://martinfowler.com/articles/itsNotJustStandingUp.html

#project
@projectsproducts

Отрывок из фильма про то, как надо ставить четкие цели: https://www.youtube.com/watch?v=pTVNinNVR5M

#project
@projectsproducts