Рубрика «управление проектами» - 374

Scrum — достаточно простая методология. Работать же по скраму не так и просто. Точно так же происходит со многими инструментами, например с покером для планирования. Практика сама по себе вполне понятная, но продуктивно её использовать в течении длительного времени затруднительно.
В этой статье я расскажу про технику, которая упрощает процесс оценок в работе скрам команды.
Итак, в чём же сложность?
Как вы знаете, story points — это относительные оценки объёма работы в истории. Нет способа оценить одну единственную историю в story points, вы всегда сравниваете историю с другими историями через story points. Покер может хорошо сработать в начале проекта, когда команды оценивает много историй в течении короткого промежутка времени.
Но позже, во время регулярной переоценки существующих историй и оценок новых историй становится значительно труднее, потому что калибровка одного story point забывается: «что такое один story point», «что-то я не уверен, что эта история действительно в 3 раза больше нашего золотого эталона», «эти две истории размером 5 не выглядят одинаковыми в размере, с моей точки зрения». Знакомые проблемы?
Читать полностью »

«Попался. Предатель. Ржунимагу». Как-то так реагируют люди, узнав, что у меня iPhone. И вот стою я перед вами, уличенный в пользовании продуктом конкурента — и признаю себя виновным.

Но, если отложить в сторону блогеров с их постами в духе «попался», на деле есть реальные причины для того, чтобы пользоваться продуктами/сервисами помимо тех, что сделаны вами (или компанией, где вы когда-то работали). Можно написать хоть тысячу твитов, но, думаю, это всё равно все знают. Подход, применяемый во многих отраслях — недооценивать или даже чураться конкуренции — подробно описан и изучен, и выводы, к которым он приводит, говорят о том, что конкуренция это хорошо.

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

Идеальное письмо инвестору
Перевод статьи Дэвида Коэна: культовая личность, основатель и директор TechStars (одного из лучших американских стартап-акселераторов), венчурный инвестор. Рассказывает о самом «правильном» письме, которое он когда-либо получал от стартапера, ищущего совет и деньги. На злобу дня российским стартаперам.

Как вы догадываетесь, я получаю кучу писем. При прошлой проверке их было более 500 в день и из них – 50 от людей, которых я не знаю. Они часто просят совета или хотят, чтобы я обратил внимание на их стартап с целью инвестирования. И это нормально, я стараюсь отвечать на все. Но однажды я получил очень отличное письмо. Оно не звучало как “холодный звонок”, оно было тщательно продуманным и очень релевантным. И вот его содержание:Читать полностью »

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

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

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

Зачем делать отчеты о поездках?

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

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

Подходы

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

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

Итак, что мы представляем из себя на данный момент? В Stack Exchange сейчас работают 75 человек, примерно половина занимается продажами (маркетинг и реклама), остальные же — созданием продуктов (разработка, дизайн, управление сообществами). БОльшая часть удалённо работающих сотрудников занимаются разработкой: 16 удалённых и 18 офисных разработчиков, сисадминов, дизайнеров. У нас команда-гибрид, которая, как мне кажется, лучшая в мире. Я руковожу отделом проектирования, так что буду говорить в основном о разработчиках, но это применимо ко всем должностям.
Читать полностью »

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

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

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

«Инвестиции русских венчурных фондов не нужны тебе»
Так мог бы сказать джедай Йода

Есть у меня мобильное приложение в App Store, которое вначале было написано для эксперимента, а потом уже переросло в полноценный проект. Проект приносил прибыль, об инвестициях я и не помышлял, дорабатывал приложение, выпускал апдейты, прога подымалась в ТОПе App Store, деньги капали. Все текло неторопливо и размеренно. Первым «змеем искусителем» стал Аркадий Морейнис, который прислал мне письмо с предложением поучаствовать в программе акселератора Plug and Play Russia. Читать полностью »

Не так давно Стивен Синофски (экс-вице-президент подразделения Windows в Microsoft) начал вести свой блог, в котором он делится мыслями о продуктах, продуктовой разработке и управлении.
Мы с любезного разрешения автора решили заняться переводом его статей. Представляем вашему вниманию перевод первой статьи из этой серии.

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

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

Естественное напряжение (sic!)

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

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

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

Палка о двух концах. Страдаете ли вы перфекционизмом?
Доброго времени суток уважаемые читатели. Насколько я понимаю себя — я перфекционист и для меня это проблема, не в плане невротического психического отклонения, а в плане того, что эта черта моего характера дурно влияет на мои/наши проекты.

Предисловие

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

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

Проблема

Перфект должен быть во всем

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

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

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


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