Управление проектами *

• «Я дважды проверил код»
• «Код проходит все тесты»
• «Ревьюер одобрил мой код»

• Всеобщность: даже если код правильно вёл себя один раз, будет ли он вести себя так во всех случаях на всех машинах и всегда?
• Ложное прохождение теста: непрохождение тестов указывает на наличие багов, но прохождение тестов не гарантирует их отсутствия.
• Отсутствие определённости: можно написать формальное доказательство корректности кода, но теперь нужно задаться вопросом, корректно ли доказательство. Потребуется доказать доказательство. Эта цепочка проверки проверок никогда не закончится.

Critique и Gerrit

У Google есть два собственных инструмента для ревью кода: Critique, используемый большинством инженеров, и Gerrit, — опенсорсный, который продолжают применять в публичных проектах.

(Вы можете сами поэкспериментировать с Gerrit в опенсорсных репозиториях Chromium и Android.)

Дэшборды

Когда инженеры логинятся с утра или когда устраивают перерыв для ревью пул-реквестов, внутри Google называемых change list, или CL, и в Critique, и в Gerrit они работают с дэшбордами, в которых можно легко вкратце просмотреть все актуальные изменения (это похоже на окно пул-реквестов репозитория GitHub, только более сложное и информационно насыщенное).

В дэшборде Gerrit есть единичный поиск, извлекающий такую информацию, как размер изменения и более подробные сведения о статусе CL (три столбца справа).

А в чем твой вклад как руководителя? ©

Как-то раз на перфоманс ревью был ошарашен отзывом одной из сотрудниц, назовём её Катя: не вижу вклад тимлида в работу команды.

На всякий случай, перфоманс ревью — процесс регулярной оценки сотрудников во многих компаниях, где учитывается мнение руководителя, коллег и подчинённых, если они есть.

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

Что интересного писали про управление проектами за неделю? Мы прочитали все публикации с Хабра, VC (и не только) и выбрали самые крутые и полезные. Читайте, сохраняйте и применяйте!

В последнее время много обсуждаются разные новомодные методики управления проектами, Agile-методики, методики разработки продукта… Или не «методики», а «методологии»?.. Или «методы»?.. Как правильнее-то?

Вроде интуитивно разница чувствуется. И даже чувствуется, что в 90% случаев (в контексте управления проектами), эти термины полностью взаимозаменяемы. Но иногда, нет-нет, но все-таки вспоминаются слова из песни: «непонятно, что конкретно ты имела в виду»*…

Надо бы разобраться…

В школе я собирал фантики турбо. Этот набор разноцветных картинок, купленных, выигранных и выменянных представлял для меня существенную ценность, настолько, что хранился в жестяной коробке под замком. До полного набора не хватало двух или трех штук из 180 вроде. В школе было еще два человека, с почти полным набором и мы точно знали колоды друг друга, и недостающие для оппонентов фанты всегда оставались лежать в коробке, чтобы не быть проигранными в "бочке". Предложи мне тогда кто-нибудь променять их на такую же стопку вечнозеленых - да ни в жисть. Сейчас я предпочитаю коллекционировать банкноты…

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

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

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

В рамках пятницы.

Есть важный вопрос, который всегда беспокоит многих работодателей не только в наших любимых СНГ, но и в принципе по миру: достаточно ли поработал наёмный сотрудник в течение рабочего дня?

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

Коллеги недавно прислали в чат фотографию, где одной из команд вручают приз за 299 проверенных гипотез за год. 

Все неловко призадумались...

За 8 месяцев его стоимость составила 1 миллиард долларов, и он стал самым быстрорастущим B2B SaaS-стартапом в мире. История успеха Slack, в которую вы можете не поверить.

В предыдущих постах я писал о том, что делать, если Заказчик постоянно генерирует новые «хотелки» по ходу проекта (клац), и что делать, если он просит эти работы сделать бесплатно (клац).

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

Вводные:

Вы находитесь в проекте, у вас есть ограниченный объем работ, бюджет и срок. Заказчик приходит и озвучивает какую-то хотелку. Вы собираете требования, описываете их (ТЗ, ФТ, ТР, что угодно), согласовываете их с Заказчкиом и считаете стоимость этих работ. Но в ответ получаете возражение «а чего так дорого, там же программист за день сделает». Ещё в конце может добавить любимое: «Вы же эксперты».

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

Поэтому этот пост будет полезен тем, кто может столкнуться с такой ситуацией в проекте. А это любой сотрудник, взаимодействующих с Заказчиком. Обычно это менеджер проекта, реже архитектор, еще реже бизнес-аналитик.

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

И последнее: речь идёт о том, что вы для Заказчика – безальтернативный Исполнитель. Если новые работы будут вынесены на ЧЕСТНЫЙ открытый конкурс, где выбирать будут ТОЛЬКО по цене, то абсолютное большинство пунктов ниже будет неприменимо.

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

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

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

Саму бизнес-концепцию Jobs to Be Done (JTBD) при желании можно свести к одному термину — клиентоориентирование. Это буквально “Работы, которые Должны Быть Сделаны”, чтобы клиент остался доволен вашим продуктом и вернулся к услугам компании в дальнейшем. Звучит в целом просто и понятно, однако существуют всеобъемлющие методы применения JTBD в инновационной деятельности и каждый из них превращает теорию работ в эффективный повторяемый метод инноваций. 

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

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

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

Привет, Хабр!

Меня зовут Ксения Змичеровская, я системный аналитик в компании R-Vision. Совсем недавно мы выпустили собственный плагин R-Object для работы с R-Vision SIEM. Наш плагин – это полноценная среда разработки с преднастроенными шаблонами объектов, подсветкой синтаксиса, подсказками и валидацией VRL-кода. Плагин позволяет выполнять автоматическое тестирование правил, проводить полнофункциональную пошаговую отладку, а также запускать тесты на производительность.

Объекты экспертизы в R-Vision SIEM составляются с помощью специального языка R-Object. Каждый объект описывается в отдельном yaml-файле с расширением .ro и может содержать блоки на языке выражений VRL. В этой статье мы подробно изучим работу с плагином от его установки до запуска тестов и написания правил.

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

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

• написание кода;
• создание и поддержка качественного ПО;
• создание и поддержка достаточно хорошего ПО экономически выгодным образом;
• управление сложностью;
• удовлетворение потребностей пользователей;
• решение задач;
• удовлетворение потребностей заказчиков;
• зарабатывание денег для организации-работодателя или для её заказчиков;
• зарабатывание денег (для себя).

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

Из статьи вы узнаете:
• На чем основаны доверительные отношения с клиентом
• Какой маркер показывает уровень зрелости отношений
• Как построить разговор
• Как доходчиво изложить информацию
• Как добиться хорошей запоминаемости
• Как использовать смысловые блоки, чтобы текст и речь влияли на принимаемые решения
• Как безопасно сделать комплимент малознакомому человеку
• Как приобрести навык быть приятным собеседником
• Как подарки или их отсутствие влияют на отношения