Это из тех книжек где пишут про необходимость создания конкурентной атмосферы в коллективе, порядок расстановки кактусов перед монитором под обложкой «12,5 шагов к эффективному менеджменту»?
Хороший ПМ зачастую выходит из исполнителей (QA/Dev/Analytics), неплохо разбирается в подотчетной системе и в состоянии адекватно оценить оценку разработчика
На эту тему есть несколько точек зрения:
1. Разработчик, которому необходимо обезопасить себя и менеджера от факапа по срокам
2. Менеджер, которому необходимо обезопасить себя и команду от факапа и продать максимально дорого в реальных условиях
3. Руководитель менеджера, которому нужно выполнить план по обороту любой ценой
4. Заказчик, которому нужно как можно дешевле при гарантированном качестве и у которого есть еще несколько предложений.
В ваккуме все это порождает порочный круг «эффективного менеджмента», «урезания костов» и прочих вещей, ведущих к плохому коду и недовольству всех участников этого шоу.
2 случая из практики:
1. крупная система, договор по сдельной оплате, каждая задача проходит 3х ступенчатую проверку трудоемкости и согласование техкомитетом (с представителями бизнеса). Архитектору приносят ТЗ на изменение куска ядра, по которому нет документации. Он, не будь дурак, вычленяет все отдельные блоки ТЗ (60 штук) и на каждый дает 3 дня. По итогу задача утверждается на ТК с трудоемкостью около 70 дней и делается за 120. Все недовольны, штрафы субподрядчику, задачу просохатили на календарный месяц по срокам сдачи.
2. Другая крупная система, договор по абонентской плате. Разработчикам дана строгая установка в оценках быть пессемистичными, согласование трудоемкости с заказчиком идет на предмет адекватности (не может отчет из 2 форм дорабатываться 60 дней, верно? :)), с бизнесом согласовываются сроки деплоя задачи на бой (сроки даются после планирования), исключение — задачи, связанные с законодательством. Процент попадания в сроки — ~95%, все довольны.
Считаю, опасно рассматривать эту проблему только с точки зрения разработчика.
приложение для айфона скорее плохо своей тормознутостью и неинтегрированностью в экосистему (пуши, центр уведомлений, стикеры). В целом у него крайне приятный интерфейс
Вы привели в сравнение Redmine (который мне тоже не нравится, к слову), который является тулзой для управления проектами, также упомянули что ведете проектную работу в студии. В редмайне есть возможность настроить воркфлоу, то есть граф поведения заявки в зависимости от условий и этапы жизни заявки.
Например: Входящая заявка — обработка — анализ — выполнение — тестирование — внедрение — контроль качества. С возможностью разработать любой алгоритм поведения заявки, KPI, отследить прогресс выполнения заявки.
Есть ли подобная возможность в RedBooth?
Если это плоская GTD система (инструмент совместной работы с распределением задач, но без настраиваемого цикла жизни задачи), то могу посоветовать обратить внимание на Asana. Про нее написан неплохой пост: habrahabr.ru/post/151162/
В бесплатной версии она позволяет вести до 10 пользователей, имеет больше возможностей по интеграции.
Технически — да. Практически — бессмысленно. Платежи по ним отслеживаются и фиксируются с твердым курсом конвертации. Плюс кошелек именованный — его проще подвязать к ЮЛ или ФЛ
Фактически ничего не поменялось. Биткоин и до этого не был официально признанной валютой, так что для юр.лиц и до этого были проблемы с выводом и обналичкой — его проблематично учесть в официальной бухгалтерии. Суть послания — «последнее китайское предупреждение, что биткоин не является официальной валютой».
Фактически, описанный способ — закономерный ответ на тренд наличия сертификата PMP. «Спрос рождает предложение». Способ крайне неэтичный и не приносящий объективной пользы человеку, его использующему.
Данная статья скорее будет интересна работодателям в разрезе того, что наличие сертификата (любого, от разработчика начального уровня до дипломанта MBA) означает всего лишь наличие сертификата, но не означает знаний. Фактически, это прямой способ пополнения рядов «эффективных менеджеров» и путь к снижению эффективности компании. Нужно реальные навыки и знания человека проверять — ситуационным собеседованием, кейсами, прямой проверкой навыков.
Гораздо эффективнее иметь PMBoK на столе и периодически обащаться к ней, равно как и к другим источникам.
о такой роскоши, как полноценное уголовное преследование, никто и не заикается. Но есть прецедент частичного удовлетворения требований, следовательно есть осязаемый шанс начать судебное преследование.
в ссылке указано, что в 1996 суд США в составе суда присяжных обязал город Филадельфия выплатить 1.5 млн$ в качестве компенсации. То есть есть возможность получить компенсацию за моральные страдания. Прецедент есть, право в США английское.
Интересно, насколько реальна возможность подать встречный иск на ФБР или руководство кинотеатра по вопросу нарушения конституционных прав гражданина США.
Подтверждаю как активный пользователь Yota с мобильным WiFi роутером. Около месяца назад качество связи драматически упало (на данный момент при тарифе 6.4 МБит/с видео на Youtube в 240p тянется с задержкой). Статистика средней входящей скорости в сети — в райное 1.5 МБит/с, роутер не перемещался. Замеры полгода назад давали среднее число 4.45 МБит/с. Сегодня общался с техподдержкой Yota, единственное что почерпнул из диалога с колл-центром — различные потоки данных (видео, сайты, музыка, торренты) у них стримятся параллельно и независимо и что проблема с перегрузкой каналов видео у них есть. Подтвердить или опровернуть эти слова не имею возможности, так как не сталкивался с кодировкой траффика по мобильным сетям и с алгоритмами оптимизации самой Yota. Как активный потребитель мобильного интернета могу констатировать, что идея всеобщего беспроводного доступа умерла. Мобильный интернет остается эффективен на уровне почта/веб-серфинг, для всего остального нужен провод до квартиры, либо вайфай в кафешках.
Продолжайте пожалуйста! Сейчас нахожусь в стадии активного общения с дизайнерами, ваши заметки позволят сделать его более эффективным для всех сторон. От себя хочу заметить, что в полный рост встала проблема №2, особенно в аспекте ооюдного решения минимализма дизайна и вылизывания мелочей
Хороший ПМ зачастую выходит из исполнителей (QA/Dev/Analytics), неплохо разбирается в подотчетной системе и в состоянии адекватно оценить оценку разработчика
На эту тему есть несколько точек зрения:
1. Разработчик, которому необходимо обезопасить себя и менеджера от факапа по срокам
2. Менеджер, которому необходимо обезопасить себя и команду от факапа и продать максимально дорого в реальных условиях
3. Руководитель менеджера, которому нужно выполнить план по обороту любой ценой
4. Заказчик, которому нужно как можно дешевле при гарантированном качестве и у которого есть еще несколько предложений.
В ваккуме все это порождает порочный круг «эффективного менеджмента», «урезания костов» и прочих вещей, ведущих к плохому коду и недовольству всех участников этого шоу.
2 случая из практики:
1. крупная система, договор по сдельной оплате, каждая задача проходит 3х ступенчатую проверку трудоемкости и согласование техкомитетом (с представителями бизнеса). Архитектору приносят ТЗ на изменение куска ядра, по которому нет документации. Он, не будь дурак, вычленяет все отдельные блоки ТЗ (60 штук) и на каждый дает 3 дня. По итогу задача утверждается на ТК с трудоемкостью около 70 дней и делается за 120. Все недовольны, штрафы субподрядчику, задачу просохатили на календарный месяц по срокам сдачи.
2. Другая крупная система, договор по абонентской плате. Разработчикам дана строгая установка в оценках быть пессемистичными, согласование трудоемкости с заказчиком идет на предмет адекватности (не может отчет из 2 форм дорабатываться 60 дней, верно? :)), с бизнесом согласовываются сроки деплоя задачи на бой (сроки даются после планирования), исключение — задачи, связанные с законодательством. Процент попадания в сроки — ~95%, все довольны.
Считаю, опасно рассматривать эту проблему только с точки зрения разработчика.
Например: Входящая заявка — обработка — анализ — выполнение — тестирование — внедрение — контроль качества. С возможностью разработать любой алгоритм поведения заявки, KPI, отследить прогресс выполнения заявки.
Есть ли подобная возможность в RedBooth?
Если это плоская GTD система (инструмент совместной работы с распределением задач, но без настраиваемого цикла жизни задачи), то могу посоветовать обратить внимание на Asana. Про нее написан неплохой пост: habrahabr.ru/post/151162/
В бесплатной версии она позволяет вести до 10 пользователей, имеет больше возможностей по интеграции.
Данная статья скорее будет интересна работодателям в разрезе того, что наличие сертификата (любого, от разработчика начального уровня до дипломанта MBA) означает всего лишь наличие сертификата, но не означает знаний. Фактически, это прямой способ пополнения рядов «эффективных менеджеров» и путь к снижению эффективности компании. Нужно реальные навыки и знания человека проверять — ситуационным собеседованием, кейсами, прямой проверкой навыков.
Гораздо эффективнее иметь PMBoK на столе и периодически обащаться к ней, равно как и к другим источникам.