войти зарегистрироваться

3 в 1: Обсуждения, задачи, документация


В нашей команде работает более 30 человек. Мы разрабатываем масштабируемые решения для web. Живем в Томске, Санкт-Петербурге и в Москве. Для организации совместной работы над задачами мы использовали task-трекер. Во время проектов создавались ценные наработки и нужно было организовать работу со знаниями. Мы пробовали различные wiki-системы. Оказалось, что большая часть наших знаний создается при решении текущих задач. Мы сталкивались с проблемами:
  • Заносить и вести все задачи в task-трекере неудобно, и поэтому сотрудники все время переходят на общение через мессенджеры.
  • Много знаний оседает в e-mail и месенджерах. Перенос знаний из переписки в task-трекер и wiki отнимает много сил и времени.
  • Если при планировании проекта в wiki была записана вся концепция проекта, то с каждым днем различий между информацией в wiki и реальным положением дел становится все больше, и поддержка базы знаний становится неоправданно трудоемкой.

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

Опрос: сколько времени тратят впустую программисты?

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

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

Для этого я прошу программистов-хабраюзеров ответить в комментах на 2 вопроса:

1. Сколько часов (минут) в день вы тратите на общение с менеджером?

2. Какой процент этого времени уходит, по вашему мнению, впустую?

Я хотел сделать более цивилизованно, в форме опросника, но потом понял, что надо учитывать программистов по типам, вроде того, что будут программисты, которые ответят:

1. 1 час
2. 30%

А могут быть программисты, которые ответят:

1. 3 часа
2. 90%

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

Funky-модель управления проектами из песочницы

Классически funky – это направление музыкального стиля ритм-энд-блюз. Но с начала 2000 года определение попало в бизнес-среду и мировоззрение людей. Здесь оно обозначает принятие решений на волне тех или иных событий, внимательное отношение к желаниям других и воплощение результатов в бизнес-решениях. Исходя из этого, можем сделать вывод, что управление проектами в стиле funk включает в себя следующие пункты:
  • неопределенность;
  • напряжение и одновременно драйв, увлечение;
  • соревнование-конкуренция;
  • поиск дифференциации, «изюминок», работа с эмоциями;
  • необходимость креативных решений.

Удачными примерами funky-проектов служили приложения вконтактов. Сейчас деятельность различных модных тренингов (не будем показывать пальцем).

Свободная ниша рынка = прибыльность бизнеса на нём? из песочницы

Почему мы прогораем


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

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

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

Почему мы никогда не составляем ТЗ. А что взамен?

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



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

6 советов для мотивации команды

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

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

Statusboard.me объявили о начале бета-тестирования

statusboard.me = Менеджмент проектов + Basecamp + Аналитика


statusboard

История проекта весьма тривиальна. Сотрудникам компании Supersteil требовался полный обзор проектов, находящихся в работе. Поэтому они решили перейти на систему управления проектами Basecamp от 37signals. Что очень положительно сказалось на рабочем процессе. Но чего-то все равно не хватало… Им требовался обзор процессов в реальном времени, так, чтобы все были в курсе дел в мгновение ока, без постоянной проверки Basecamp.

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

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

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

Клещи. Получаем информацию из песочницы

image
Ботинком мы пытаемся решить проблемы связанные со временем: несвоевременные ответы (пинать заказчика), несвоевременное выполнение (пинать разработчика), несвоевременная информация (пинать руководство). Клещи нам нужны для решения проблем связанных с информацией.
Информационные проблемы бывают 2 видов:

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


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