В октябре 2019 года прошла первая Конференция Интеграторов Планфикса, или коротко — #КИП2019.
Спикерами выступили действующие интеграторы и продвинутые пользователи из самых разных сфер.
Посетили мероприятие более 130 человек в офлайне и около 40 человек в онлайн-трансляции.
Организатором выступил Степан Чельцов, интегратор из Первого интернет-проекта.
Приглашенный гость — Дмитрий Гончаренко, один из основателей Планфикса.
Недавно мой коллега Алексей Горностаев выразил давно обсуждаемое недовольство качеством технических заданий на разработку или создание интеграций с внешними системами. Попробую выразить свою позицию.
Большинство Заказчиков не обладают штатными специалистами, которые способны сформулировать ТЗ на разработку, а собственная занятость и представление о желаемом решении часто воплощается в простые текстовые пояснения на том уровне, который доступен Заказчику. Это не хорошо и не плохо, это факт, с которым работают потенциальные Исполнители работ.
Мы живем в несовершенном мире, потому эмоционально реагировать на подобные ситуации не имеет смысла, ведь повлиять системно на это невозможно одной компании или человеку. Но можно помочь Заказчику стать немного системнее. Покажу на примере, как это делаю в своем Агентстве для некоторых проектов, где Заказчики готовы вовлекаться.
С конца декабря 2017 года один из моих клиентов запросил проведение выездного анализа процессов и составление Проектных требований по итогу анализа. Первую часть работы я прекрасно знаю, но Проектные требования в первой своей версии напоминали классическое ТЗ на разработку IT-проекта. И это не понравилось Заказчику. Он хотел Проектные требования, как предварительный этап до ТЗ. Это был вызов к компетенции.
Поиск в интернете не дал результата, кроме как изучить серьезные книги мудрых авторов. Времени не хватало, книг в продаже недостаточно, электронных вариантов не купить. Логические рассуждения заставили разработать собственный подход к созданию проектных требований на основе пояснений Заказчика.
Проектные требования — документ, которые позволяет составить структурированное представление о том, как Заказчик представляет себе работу будущей системы. ПТ включают в себя алгоритмическую часть, функциональную и ролевую. На его основе проходят обсуждения среди трудового коллектива, корректируется ролевая модель, появляются новые вопросы. Но при этом Заказчик получает понимание всех процессов, происходящих в системе на доступном ему языке. Вот как это выглядит на примере простого процесса авторизации в системе.
*В этом месте смотрим скриншот.
Новый документ был принят без замечаний, проведен дополнительные обсуждения и уточнения, сейчас внесены правки для перехода к макетированию и ТЗ.
Это один из множества процессов, которые происходят в Системе. Часть из них полностью технические и для пользователя представляют интерес только с точки зрения названий элементов интерфейса. Но другие процессы и функциональные сценарии дают понимание, как именно Пользователь будет работать в системе:
Главное отличие ТЗ от Проектных требований в том, что на основе Проектных требований можно составить макеты интерфейсов и подготовить ТЗ, а на основе только ТЗ получается оторванный от реальности макет и «иначе работающий проект».
Я знаю, что есть международные стандарты и наши ГОСТы по составлению документации на разработку проектов. Эти документы невозможно читать неподготовленному человеку, их готовят месяцами, и они создаются только ради соответствия этим требованиям, но не для облегчения труда Разработчика. Эта работа в разы дороже той, которую предлагаю в Агентстве я.
Я упоминал еще один вид документа — Бриф. Этот документ в большинстве случаев является кратким лирическим описанием Проектных требований. Там нет сложных конструкций, это скорее развернутая расшифровка того, что хочет клиент с точки зрения Исполнителя, и этот бриф очень легко обсуждать с Заказчиком, но потом обсудить решение с Разработчиком будет так же сложно, как и без него.
Одна из функциональных реформ моего Агентства в 2018 году — составление проектных требований на проекты в комплексе, и на локальные микрозадачи по разработке или поддержке. Подобные документы мы сначала обкатаем на нескольких проектах, а в дальнейшем распространим как стандарт по всем нашим проектам на всех фазах.
Составление Проектных требований — трудоемкая работа менеджера проекта со стороны Заказчика или со стороны Исполнителя. В нашем случае мы новаторы, потому составлять будем сами и обучать Клиентов, которым понравится подход. Так же Проектные требования решают одну из важнейших проблем всех проектов — проблему учета времени менеджера и тестировщиков, который работает на стороне Исполнителя.
Большинство Заказчиков оценивают работу только по трудозатратам непосредственного исполнителя задачи, но про сопровождение этой работы со стороны Менеджера в виде переговоров и постановке задач на исполнение все забывают и не желают оплачивать эту часть работы. Подрядчики решают эту проблему через повышение стоимости часа, в которую закладывают и время менеджера, и время других технических специалистов. Но повышать стоимость часа зачастую сложно для тех ниш, в которых Подрядчики работают. И тут начинается свистопляска с отбиванием стоимости тура менеджера так, чтобы казалось убедительным. Я против такого подхода, и я за чистый подход к раскадровке трудозатрат.
Мой подход помогает четко понять, чем занимается менеджер, почему он стоит не дешевле технического специалиста, и почему его работа важна на более высоком уровне, чем непосредственная разработка. Ошибки на уровне подготовки могут вылиться в серьезны ошибки разработки, а исправление может стать и вовсе невозможным.
Может возникнуть вопрос, почему этим занимается менеджер, а не Архитектор систем, или Тимлид, или Технический директор, или Аналитик? Ответ прост — они технари, а клиенты — не технари в большинстве случаев. Менеджер — единственное звено, которое осведомлено о проблемах Клиента, о проблемах разработки каких-либо решений, и он консультируется со всеми упомянутыми выше, чтобы составить Проектные требования.
Чтобы перейти к ТЗ от Проектных требований, мы макетируем интерфейсы и экраны. Очень грубо, так как это помогает технарям составлять ТЗ с наглядной картинкой перед глазами. Они вносят свои помарки в макеты, описывают сущности, а дизайнер дорабатывает макеты по мере поступления замечаний и составления ТЗ.
Вы все верно поняли, когда дело дойдет до ТЗ. Подключаются к работе технари, которые добавят к проектным требованиям то, без чего проект не может быть выполнен — информацию КАК сделать описанную систему. Такой документ можно считать полноценным руководством по запуску проекта или отдельных решений.
Вы можете задать еще один вопрос.
А если я хочу подешевле и без вот этого всего, но «как всегда» и «как у всех», но при этом хочу получить хороший продукт, что делать?
Все просто. Для этих случаев вам нужно всего 5 действий:
То есть, залог экономии в максимальном снижении затрат на подготовку со стороны Исполнителя и максимальном вовлечении вас в проект на нужных этапах. Нарушение любого из этих пунктов грозит повышением стоимости проекта, сроков и появлением непредвиденных рисков.
Пару лет назад я помогал Илья Жаркий с составлением ТЗ на работы. Я показал пример, сказал, сколько стоит составление ТЗ, а он не поверил в объективность стоимости. Но как профессионал — полностью вовлекся в составление ТЗ, предоставил его разработчикам.
За несколько итераций и торга ни у меня, ни у Ильи не осталось вопросов, почему Разработчик просит те деньги, которые были в КП. И, надо сказать, что цена была выше первых вариантов от Подрядчика, но оценка плавала и вызывала сомнения. Но с последним вариантом ТЗ и принятием коммерческого со стороны Ильи, он получил еще один примерно такой комментарий со стороны менеджера Исполнителя на вопрос о наличии вопросов по ТЗ:
Насколько я знаю, проект успешно завершился и бюджет не был превышен. Со стороны Исполнителя я так же слышал благодарность за хорошего клиента.
Буквально на днях приходит запрос на оценку разработки собственной системы email-рассылки на основе самописной CRM. Искушенные в разработке и в email-рассылках сразу понимают, что при любой адекватной стоимости часа разработчика, полноценным сервис будет только за месяцы или годы разработки с соответствующей командой и бюджетом.
Профессионал во мне задает вопрос, почему бы не интегрироваться с текущими рассыльщиками? Ведь это быстрее, дешевле, и во много раз лучше собственной разработки. Но суть бизнеса оказалась настолько узкой, что решение рассылать все через свой сервис оказывается единственным.
Второй этап — расшифровать 14 тезисов, которые представлены в запросе, чтобы разработчики могли оценить разработку и понять этапы запуска проекта. Это простые пункты, которые можно назвать от части названиями процессов, а отчасти размышлениями на тему. Это можно называть даже Брифом проекта, но весьма поверхностным. О Брифах выше отдельно.
Для проекта я быстро (2 часа) подготовил Проектные требования для оценки работ. И уже сутки идет обсуждение, функционала по Требованиям, а не по тезисам.
На этой позитивной ноте заканчиваю. Приглашаю к дискуссии в комментарии.
P.S. О стоимости часа мы поговорим как-нибудь отдельно, этот пост я уже несколько недель не могу дописать.
По мере роста компании, привычных инструментов становится недостаточно. В первую очередь, это мешает быстро расти и масштабировать бизнес. Яркий признак проблемы — новые сотрудники дольше учатся работать, а руководители не могут посвящать время обучению людей и контролю проектов.
Система Мегаплан позволяет выполнять многие задачи, но ко мне обращаются за переходом с этой системы в связи с периодическими сбоями и желанием получить больше функционала.
Работа с Мегапланом строится по стандартному сценарию, длительность работы около 50 часов после полного понимания предстоящей работы.
Система Битрикс24 создана для управления проектами, но сложность работы в ней заключается в сложности настройки продукта. Функции, на которые в Планфиксе уходит 1-2 часа, в Битриксе реализовываются за десятки часов.
Как пример, спросите любого партнера по интеграции Битрикса, сколько займет создание счета и акта выполненных работ в Битриксе. В Планфиксе работа займет 15 минут.
Работа с переходом с Битрикс24 на Планфикс так же идет по стандартному сценарию, длительность работы выше Мегаплана — около 80 часов после полного понимания предстоящей работы.
Система канбан-досок Трелло хорошая и выполняет множество интересных специфических задач. Но в какой-то момент этого перестает хватать из-за сложности аналитической работы по большому числу проектов, а вхождение в курс работы нового сотрудника — очень утомительно для руководителя.
Переход на Планфикс обычно не подразумевает перетаскивания задач. Я строю систему и в какой-то момент все переходят в Планфикс. Для страстно любящих канбан-доски, в Планфиксе есть специальный инструмент — Планировщики.
Работа по внедрению Планфикса в организацию и интеграции всех процессов в организацию и Планфикс — работа по взаимодействию двух сторон. С моей стороны идет полное погружение в работу и такой же отдачи ожидаю от Заказчика или его представителя.
По всем вопросам интеграции прошу обращаться на почту:
В ноябре 2017 года я анонсировал запуск проекта Кудалибо.ру, и захотел указать страницу как место работы. Но стандартные средства Фейсбука не позволили мне этого сделать. Пришлось решить проблему нестандартно, о чем и будет эта заметка.
Классический путь указания страницы FB как места работы, это зайти в свой профиль в раздел «Информация», далее в «Работа и образование»:
Заходим в раздел «Информаци» и «Место работы»
Здесь нам остается только нажать на «Укажите место работы», и начать заполнять поля.
В простой ситуации вы просто начнете заполнять поле с организацией и она появится в списке без каких либо проблем:
Выбираем свое место работы из списка
Но что делать, если страница компании не появляется в списке вариантов фейсбука?
Если страница не появляется в списке предложений фейсбука, даже если вы указываете все правильно, есть один хитрый метод.
В первую очередь, вам надо зайти на страницу, которую планируете добавить, и перейти в раздел «Информация». В самом низу будет
В разделе «Информация» у любой страницы
После этого идет к нашему профайлу и выбираем любую страницу, которую предлагает Фейсбук в списке:
Нажимаем правой кнопкой мышки и выбираем опцию «Просмотреть код», но обязательно в этом экране, а не в другом:
Указываем любую страницу
Нам показывается непонятная абракадабра, но блоком выше надо найти пункт с VALUE=»123123123«, где 123123123 — ID страницы компании, которую вы случайно поставили. Нажимаем 2 раза на это значение, и меняем на ID нужной нам страницы, который мы уже себе скопировали:
Открываем просмотр кода
После этого нажимаем «Сохранить изменения», и наша страница появляется в списке рабочих мест:
Заменяем value страницы на нужный нам ID
После этого можно исправлять свою должность и описание работы, даты и прочее.
Страница добавлена в место работы
Новое место уже можно редактировать
Все изменения сохраняются
Для доступа к сервису PR-CY.ru с дисконтом рекомендую использовать скидочную ссылку:
Уже давно пользуюсь сервисом управления проектами Планфикс, и несмотря на постоянные улучшения и текущие удобства, приходится делать для себя хитринки.
Один из важных инструментов для меня — Напоминания. Функционал у них очень продуман, но есть проблема — когда приходит напоминание, надо заходить по ссылке и смотреть, что там надо делать. Я придумал писать в заголовке напоминания то, что мне нужно. А зачастую это звонки определенным людям в определенное время.
Создание напоминания в Планфиксе
Когда тригерное уведомление срабатывает, я получаю в Телеграмме сообщение с номером телефона и сутью звонка. Простое нажатие вызывает функцию звонка, общаюсь с человеком и по итогу разговора делаю ответ на это уведомление с описанием сути разговора. Если звонков предстоит много, я делаю сразу много уведомлений для перезвона на разные дни и время с копипастом одного заголовка.
Получаем уведомление в Телеграм на десктопе
Получаем уведомление в Телеграм на телефоне
Надеюсь, что в отдаленном будущем у них появятся шаблоны уведомлений, и ручной копипаст отойдет на второй план. Так же надеюсь, что появится возможность выбирать, получать напоминание только в Telegram или только по email, иногда это важно.
Есть два вида исполнения задач — когда задача выполняется непосредственно вами или когда ее будут исполнять другие.
При непосредственном исполнении задачи вы обычно знаете что делать, даже если вам ее поставили руководители или вы сами. Постановщики задач в этом случае для вас сделали самое главное — сформулировали суть задачи, критерии ее принятия и отклонения, указали сроки и бюджет, если он требуется. Если у вас возникают проблемы и вопросы, они выливаются в запросы-уточнения, самостоятельный поиск, консультации с коллегами и прочие варианты поиска решений.
На выходе с такой задачей у вас может быть 2 решения: задача будет выполнена по критериям или выполнена не будет, несмотря на множество попыток ее выполнить. Это неприятно, но такие задачи бывают, когда выполнение совершенно от вас не зависит или в принципе невозможно с заданными вводными. Негативный сценарий вы обязательно опишете с причинами невыполнения и вариантами выполнения при коррекции требований.
Второй тип задач, когда постановщиком являетесь вы, предъявляет определенный список требований к вам:
У каждого пункта есть своя специфика, у каждой профессии есть свои нюансы. Возможно, что роли людей совмещаются или разделяются принудительно на множество мелких. И вы можете оказаться на любом уровне иерархии.
Объединяет эти пункты самое главное — ваша готовность правильно оценить задачу, вовремя сообщить о необходимости изменить условия, а так же быть пунктуальным куратором поставленных задач.
Вспомним, что задачи вы не сами придумываете, у вас есть некое руководство, или как минимум — заказчик проекта. И если у вас есть коллеги, подчиненные тому же начальнику, значит у начальника задач больше ваших пропорциональной количеству ваших коллег.
Руководство подчиненными, у которых много своих проектов и задач — одна специфика. Руководство сотрудниками, выполняющими несколько проектов, и все они пересекаются в проектах так или иначе — совершенно другая работа.
В первом случае руководитель может проводить встречи с отдельными сотрудниками с разрезе проектов, не отвлекая остальных от работы. Во втором случае встречи превращаются в летучки с разбором всех проектов компании.
Последний вариант объединяет команду, но и распыляет ее силы на проекты — все делают все по чуть-чуть. Первый вариант позволяет концентрироваться, но команда может быть сильно разрозненной, и совсем не факт, что они будут помогать друг другу на добровольной основе.
Вспомним о руководителе. Несмотря на персональную ответственность менеджера за задачи в проекте, руководитель должен уметь вовремя находить риск невыполнения проекта в срок, видеть срыв работы или опережение сроков в общем плане проектов и задач, а также контролировать общую экономику проекта на старте и в процессе. Удобный инструмент контроля и мониторинга — важный вопрос операционной работы, который позволяет не скатиться до микроменеджмента. А каковы последствия микроменеджмента в проектах — мы с вами обсудим на следующем занятии.
Ни для кого, надеюсь, не секрет, что делегировать придется рано или поздно. Что делегировать — вы итак поймете. А вот как делегировать — вечный вопрос. Как доверить вопрос человеку? Как проконтролировать качество исполнения? Об этом и будет заметка.
В моей истории было несколько попыток делегирования. Они все начинались на энергичном рассказа о задаче, которую надо закрывать. Я рассказывал об особенностях, тонкостях, нюансах. Просил спрашивать меня в любой непонятной ситуации, и доверял работу. И смотрел, что будет происходить дальше.
К сожалению, у меня создавалось ощущение, что я говорил на китайском, а человек просто кивал из приличия. И попытки скорректировать работу приводили к тому, что человек обижался и уходил под предлогом «не сработались». Да, моя вина тоже есть — я слишком сильно хотел, чтобы человек понял и выполнял все так же как я. Пошел другим путем.
На второй и третий раз я описывал все текстом, алгоритмами, инструкциями и типовыми ситуациями. Я дольше ждал, дольше корректировал, терпел и старался помогать. Результат был тот же..
Я пошел совсем другим путем, решил не рассказывать почти ничего, бросая человека в омут. Примерно и образно все рассказал, доступы дал — и в бой! И удалось, хотя, наверное, повезло.
Новый менеджер влился в работу, задал кучу вопросов, подхватил все вопросы и.. все полетело без моего непосредственного участия! В августе будет год, как мы работаем совместно. А полезность и важность этой работы я ощутил, когда менеджер ушел в отпуск.
У меня вдруг родилась мысль, что делегировать лучше можно было только самому себе или ближайшему родственнику. Успешное делегирование — это то чувство, когда попросил отца сделать что-то и абсолютно не переживаешь, что все будет сделано еще лучше, чем ты сам сделаешь, а за сомнения будет еще и стыдно.
Делегировать надо учиться. Придется много пробовать. Придется много ждать и пробовать. Это будет недешево, и это будет бесить. Но этот путь придется проходить.
Лучше начать раньше, переключая часть работы на другого человека. Шаг за шагом придет понимание, что люди хорошо усваивают, а что плохо. Как вы можете объяснять, что нужно объяснять, а что нужно оставить для самоизучения. Наверное, это самая тонкая материя — научиться понимать себя и других.
https://www.facebook.com/notes/
Есть такой блогер по имени Елена Торшина. В своем блоге она эмоционально разносит разные вопросы из наболевших проблем рынка. Пока она писала для себя и коллег, было бы и норм, но когда большие издания начинают перепечатывать ее без должной коррекции, начинаются сложности на всем рынке.
Во-первых, нигде не упоминается, что Торшина занимается больше пиаром, а не рекламой. И никто нигде не пишет, насколько успешна ее работа.
Во-вторых, терминология подразумевает, что если у тебя бюджет на рекламу меньше заявленного, значит ты «упырь». И шансов у тебя нет даже при кратном увеличении бюджета.
В третьих, Торшина сразу записывает людей с небольшим бюджетом в мудаков, которые высасывают мозг за каждую копейку. Исходя из этой логики, клиенты с бюджетом выше 500 тысяч вообще никак не считают копейки и не спрашивают с подрядчика результат работы. И это странно, почему люди не хотят получить отчет по результатам дорогой рекламной кампании.
Там же в списке Торшина записывает всех «упырей» в идиоты, потому что им бесполезно объяснять механизмы работы. Почему заказчика должны волновать эти вопросы — Торшина не пишет. А они не должны волновать никого, кроме исполнителя, если задачи не ставились в деталях.
И получается, что все, кто ранее и сейчас работают с Торшиной и не подходят под ее параметры — упыри, мудаки и идиоты. А все остальные текущие клиенты — молодцы и красавчики.
Я пишу это ровно потому, что это непрофессионально. Можно думать что угодно у себя в кулуарах, но унижать клиента нельзя ни в каком виде.
Если не нравится клиент и его товар, не нравятся условия работы — не работай, откажись, направь к другим или на дообучение. А если ты этого не делаешь, берешься за работу и страдаешь, значит все твои статьи полный высер.
Сначала надо подтянуть грамотность, конечно. Просто почитайте, закажите консультацию со специалистами и вникайте в детали. Да, если вам это важно, вникайте. Или научите того, кто на вашей стороне будет вникать. Пока на рынке есть агентства и специалисты, разделяющие позицию позицию Торшиной, ваш бюджет в рекламу будет просто слит в унитаз.
При выборе подрядчика поинтересуйтесь, как он относится к «творчеству» Торшиной. Если знаком и не негативно, то лучше с ними не работать. Если ничего не слышал, то скорее всего не следят за рынком вообще, и лучше не работать.
А работать остается или самим или с теми, кто не согласен с Торшиной в ее миропонимании.
Подумайте отдельно, что вам на самом деле нужно — реклама или продажи. Если продажи, лучше обращайтесь к тем, кто занимается маркетингом комплексно и в привязке к продажам, а не к стоимости перехода на сайт. Мною проверено агентство «Фэтфокс», не дешево, но того стоит.
Сайт hr-tv.ru запросили комментарий: «Какие, на ваш взгляд, наиболее распространенные заблуждения есть у начинающих и опытных руководителей?»
Мой ответ:
Противоположное предыдущему пункту иллюзия. Комментирует Степан Чельцов, генеральный директор Thepresents.ru:
Большинство людей не понимает, что значит руководить, а значит это — работать системно и в команде:
— найти сотрудника умнее себя;
— дать ему возможность и инструменты работы;
— построить и донести до подчиненных критерии оценки их труда;
— не перегружать человека сверх необходимого;
— разговаривать с людьми и доносить до них суть работы и ценности.
Большинство встречаемых мною руководителей часто плохо отдают работу людям, мешают им работать постоянными отчетами-вопросами-совещаниями, меняют правила работы или не соблюдают их сами, перегружают людей задачами, и не слушают обратную связь с мест
Источник: http://hr-tv.ru/articles/semnadtsat-zabluzhdenii-lidera.html
Дополню комментарий. Каждый руководитель заблуждается по поводу своих подчиненных. Мы верим им больше нужного, не доверяем, хотя можно. Отпускаем некоторые вопросы, хотя надо бы усилить контроль. Или зажимаем гайки, хотя все вполне было нормально. Проблема не в самодурстве, хотя и оно присутствует.
Все дело в недостаточной проработке системы взаимоотношений. Когда люди не знают всех своих обязанностей, когда обязанности и приоритеты меняются в течении недели или дня — ничего хорошего не будет. Исполнитель в ситуации непонимания развития событий начинает делать что? Правильно, только то, что не изменилось — базовую и неважную работу, а задачи с высоким приоритетом остаются на обочине ровно по одной причине — руководитель не выстроил систему приоритетов и мешает сотруднику выполнять свою работу.
Вторая сторона проблемы — руководитель ставит и принимает задачи в своей системе координат, а люди работают в другой. Сначала вы накидали задач и думаете, что там все просто. Или вообще не думаете, что там у подчиненного с нагрузкой, а он просто пытается вытянуть все свалившееся, или не пытается. В это время руководитель еще и спрашивать начинает, ругается, еще накидывает, приоритет меняет, а прогресса всеравно не будет, не тянет человек.
Для начала ее надо осознать. Причины в руководителе и всей его вертикали управления.
Далее надо провести срез всех задач на сотруднике, выписать их с дедлайнами и подзадачами. Все задачи обсудить и расставить приоритеты, сроки, объяснить, как задачи будут приниматься. Если получится объяснить человеку ценность его работы в целом, показать связку с другими сотрудниками, будет замечательно. С каждым сотрудником происходит такая работа постоянно, если не раз в неделю, то раз в месяц точно.
Помимо личных встреч нужно проводить одну общую встречу, обсуждать проекты друг друга, выявлять связки людей в разных задачах, спрашивать проблемы и согласовывать приоритеты между сотрудниками. Это поможет наладить горизонтальные связи в коллективе, чтобы результаты получались сами по себе в результате нормальной работы, а не по приказу свыше.
Я люблю технологичный подход. И каждый раз в каждом проекте рассказываю, что надо определиться с центром управления/центром принятия решений. Для себя я выбрал управление проектами через Планфикс. Все задачи мы помещаем в них, ставим приоритеты, сроки и знаем, что и с чем нам надо связать, чтобы заниматься делами эффективно.
Я могу организовать такую работу и просто через Gmail и Календарь, все будет работать как часы, все будут связаны друг с другом и будут видеть задачи друг друга, но это не так эффективно, как могло бы быть.
Мои друзья делают такие же штуки в MS Outlook, Basecamp’ах, Worksection и прочих сервисах. Их много, но внутри компании должен быть один для всех, или прочие решения должны быть легко интегрируемы между собой. Такое может сделать Планфикс с Гугл.Календарем, кстати.