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

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

Цели и задачи

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

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

Третья цель. Люди, занятые на большом проекте, часто перегружены работой. Не хватает времени на непосредственную работу – не то, что подготовить отчёт. Тем не менее, лучше придерживаться принципа – упрощать работу коллегам. Как бы вы ни были заняты, а ваши коллеги могут быть заняты сильнее. Поэтому, не смотря на то, что часто необходимая информация может быть извлечена потребителями самостоятельно, лучше готовить данную информацию для ваших коллег самим. Согласитесь, что гораздо легче прочитать уже кем-то подготовленный отчёт, чем извлекать ту же самую информацию самостоятельно из системы контроля задач.
Читать полностью »

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

Цели и задачи

  1. Своевременно обнаруживать препятствия, с которыми столкнулись инженеры при выполнении своих заданий.
  2. Находить зависимости между заданиями разных инженеров.
  3. Своевременно определять, какой задачей занимается инженер – той, что поставил ему менеджер или ведущий программист, или той, что он выдумал себе сам.
  4. Объективно оценивать результаты работы каждого сотрудника.

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

Анализ работы команды и того, как она была проделана

Управление ретроспективой или взгляд в прошлое: Руководство Gov.uk - 1

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

Наверняка многие слышали о системе управления проектами Asana. Дастин Московиц, ранее известный как соучредитель Facebook, привлёк многомиллионные инвестиции для своего проекта.

В начале 2013 года, когда мы всем агентством в очередной раз лихорадочно пытались сбежать из неповоротливых «Битрикс 24» и «Мегаплан». Я протестировал Asana и сказал: «ну что инвесторы нашли в этом проекте? Здесь же ничего нет!» Однако со временем понял: как и любая легендарная система, Asana имеет свою философию, своё ДАО, без знания которых ларчик не откроется.

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

В качестве предисловия

Началось все в феврале 2014 года с приглашения посетить конференцию AgileDays2014. Вечером того же дня я засел на сайте конференции, чтобы выделить интересные мне темы и спланировать посещение докладов. Через 5-10 минут я уже смотрел запись выступления с AgileDays 2013 “Свобода и ответственность” Антона Волкова из Alternativa Platform.

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

Для того, чтобы взрастить чувство ответственности нужно:

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

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

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

От ныне классического сервиса OkStupid до эксклюзивной новинки The League, существует множество веб-сайтов, которые можно использовать, чтобы разнообразить свою интимную жизнь. Но ни один из них не сравнится с сервисом знакомств в реальной жизни – по крайней мере, так считают основатели недавно запустившегося проекта под названием «Tawkify». Читать полностью »

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

В функционировании любого растущего бизнеса — не только в IT, но и в других областях — наступает момент, когда заброшенные в дальний угол и уже успевшие покрыться благородной патиной проблемы становится невозможно игнорировать. Их последствия дают о себе знать в самых неожиданных ситуациях. Есть не один десяток методик, позволяющих разобраться с проблемами и заставить бизнес работать, но начинать приходится всегда с одного и того же: анализа первопричин этих самых проблем. И сегодня Роботам хотелось бы поговорить об этом — не только переведя статью о методах поиска первопричин бизнес-тренера по IT и специалиста по Agile, Scrum и Kanban Хенрика Книберга — но и рассказав о том, как Роботы исправили несколько собственных поломок. Статья публикуется с сокращениями, полная версия доступна в нашем блоге на Хабре.

Управление IT-компанией: разлучаем теорию с практикой - 1

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

image
День 18 ноября 2014 года стал датой публичного релиза редактора Optimizely’s для iOS. Это было весьма значимым событием, так как релиз ознаменовал собой окончание многомесячного публичного бета-тестирования, на протяжении которого сотрудники компании получили массу пользовательских отзывов, в соответствии с которыми занимались внедрением множества недостающих функций (о том, как зарабатывать на продукте или сервисе до его запуска — здесь). Но до момента запуска приложения оставалась одна проблема, в процессе решения которой сплотилась вся команда: они не чувствовали гордости за свой продукт. Для исправления этой проблемы ребята и вышли за рамки концепции MVP (англ.: «Minimum Viable Product» — «Минимально жизнеспособный продукт»), расширив её до MVPP: «минимально жизнеспособный продукт, которым мы гордимся» (англ.: «Minimum Viable Product we’re Proud of»). Ниже — история о том, как все это было, чему сотрудники из Optimizely научились по ходу работы, а также — советы по разработке, которые должны помочь читателям создавать классные продукты. Советы с точки зрения тех, кто только что прошёл этот путь.Читать полностью »

Муда, что по-японски означает «потери» — это любая деятельность, которая потребляет ресурсы, но не создает ценности для клиента. (Источник).

8 сортов муды в твоей веб-студии - 1

Эта короткая заметка для тех, кто системно ищет, где его студия теряет деньги. Похвальное занятие в наше весёлое время.

Хорошо систематизировали виды потерь ребята из Toyota. Тойотовцы выделяют 7-8 видов муды, потерь на производстве. Посмотрим, есть ли аналоги между потерями в автомобилестроении и работе студии.
Читать полностью »

Автор книги Lean Startup Эрик Рис и Илья Королев (ФРИИ) о преимуществах «бережливого» подхода к созданию компаний - 1

Мы продолжаем публиковать в блоге ФРИИ материалы нового формата — для того, чтобы сравнить подходы к развитию стартапов в США и России мы устраиваем перекрестные интервью, в ходе которых на одни и те же вопросы отвечают знаменитые предприниматели, инвесторы и ИТ-эксперты двух стран.

В первом выпуске о причинах успеха и провала стартапов рассуждали Пол Грэм (Y Combinator) и Дмитрий Калаев (Акселератор ФРИИ). В сегодняшнем материале тему «бережливого» подхода к созданию стартапов обсудят автор книги Lean Startup Эрик Рис и инвестиционный менеджер ФРИИ Илья Королев ilyakorolev.Читать полностью »


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