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

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

10 лет назад у молодого и зеленого менеджера проекта случился удачный опыт внедрения чего-то похожего на скрам в одной из страховых компании. Энтузиазма хоть отбавляй. Коллеги айтишники всячески поддерживали. Помогало программистское прошлое. Но в какой-то момент появилась непробиваемая стена: Agile подход работал внутри ИТ, но со скрипом воспринимался вне няшного айти пространства. Нужна была синхронизация с другими отделами и смена уклада работы всей компании. Тогда полноценный переход не случился, но год назад удалось воплотить Agile трансформацию на другом проекте в финансовой организации с вовлечением более 100 человек. Возможно ли такое в природе?

Этот пост про единственное, что имеет значение для нового стартапа.

Но сначала немного теории:

Если посмотреть на широкий срез стартапов – скажем, 30, 40 или больше, чтобы отсеять чистые случайности и поискать закономерности – будут очевидны два факта.

Первый очевидный факт: успех варьируется крайне широко – некоторые стартапы безумно успешны, некоторые очень успешны, многие несколько успешны, и, многие, конечно, совершенно неудачны.

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

Команды варьируются от выдающихся до образцово дурных; продукты варьируются от шедевральных до едва работающих; а рынки варьируются от процветающих до коматозных.

Это заставляет задуматься – что больше всего соотносится с успехом – команда, продукт или рынок? Говоря прямо, что ведёт к успеху? Или что опаснее: плохая команда, плохой продукт или плохой рынок?

Мы поговорили с Андреем Юнисовым — директором по маркетингу в швейцарской компании Bacula Systems. Ранее он работал с Билайн, МТС, Мегафон, Tele2, Lamoda и другими известными брендами. Андрей рассказал про сервис SimilarWeb и про то, как анализ конкурентов поможет выстроить стратегию, спланировать бюджет и допустить меньше ошибок.

Эта статья — конспект интервью с Андреем.



Инструменты, которые позволяют анализировать конкурентов, появились в России недавно. Я имею в виду численный формат. То есть не просто зайти на сайт и посмотреть, как расположены картинки и тексты, а именно получить серьёзные численные данные.

Перевод статьи подготовлен специально для студентов курса «Framework Laravel».

---

Привет, я Валерио, инженер-программист из Италии.

Это руководство предназначено для всех PHP разработчиков, уже имеющих онлайн-приложения с реальными пользователями, но которым недостает более глубокого понимания того, как внедрить (или значительно улучшить) масштабируемость в своей системе, используя очереди Laravel. Впервые я узнал о Laravel в конце 2013 года на старте 5-й версии фреймворка. Тогда я еще не был разработчиком, вовлеченным в серьезные проекты, и одним из аспектов современных фреймворков, особенно в Laravel, который казался мне самым непостижимым, были очереди (Queues).

Управление командой — это настоящее призвание. Хороший менеджер знает сильные и слабые стороны команды, с которой он работает, и умеет грамотно и не без воображения распределять эти ресурсы. Но в игровой индустрии есть свои особенности. В нее приходят люди творческие, страстные и где-то хаотичные. И здесь начинаются проблемы. Руководители проектов в Banzai Games собрали для вас топ-5 книг, которые помогут вам стать тем самым человек, который решит их и за которым захочется идти.

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



Под катом — видео и расшифровка доклада Артема Ерошенко из Qameta Software с конференции Heisenbug. Он представил несколько разработанных простых и элегантных решений, которые помогают команде Яндекс.Вертикалей оценивать покрытие тестов, написанных автоматизаторами тестирования. Артем расскажет, как можно быстро узнавать, что покрыто, как покрыто, какие тесты прошли, и мгновенно смотреть наглядные отчеты.

Статья посвящается всем тем, кто:

• до сих пор не может уснуть, после увиденной схемы паттернов из книги Банды Четырех
  
  
  Страшная вещь

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

Что значит «научиться»?

Прежде, чем говорить о том, как эффективно учиться, не помешает дать определение слову «научиться».

Научиться — значит быть способным извлечь знание из головы тогда, когда это нужно.
Значит, неважно как много вы тратите время на обучение, если оно не позволяет вам пользоваться знаниями — оно бесполезно.

PSR — Чуть больше, чем стиль оформления кода.

Как показала практика, многие PHP-разработчики знакомы с аббревиатурой PSR. Однако большинство все еще ограничены знанием, что PSR это стандарт оформления кода.

Ребята из PHP-FIG (PHP Framework Interop Group), группа концепций совместимости PHP, которые занимаются развитием PSR (PHP Standards Recommendations) шагнули далеко вперед. Поэтому давайте разберемся, что из себя представляет PSR…

Микросервисная и модульная системы — это типы архитектуры IT-решений.

При работе с модулями мы дорабатываем коробочную версию существующего IT-продукта.

Под коробочной версией имеем в виду монолит, готовую систему с ядром, которая поставляется всем заказчикам одинаково, «как есть».

Доработка состоит в создании модулей с недостающим функционалом.

Новые модули получаем путём переиспользования частей монолита (ядра или других модулей).
Бизнес-логика прописывается внутри монолита: для программы (приложения, сайта, портала) есть одна точка входа и одна точка выхода.

При работе с микросервисами мы создаём IT-продукт с нуля, составляя его из «кирпичиков» — атомарных микросервисов, отвечающих за отдельный небольшой процесс (отправить письмо, получить данные по заказу, сменить статус заказа, создать клиента и т. п.).
Набор таких блоков объединяется бизнес-логикой в общую систему (например с помощью BPMS). Несмотря на наличие связей, каждый блок автономен и имеет свои точки входа и выхода.

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

И снова здравствуйте. Перевод данной статьи был подготовлен в преддверии старта курса «Agile Project Manager в IT».

---

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

Привет-привет! Мы вновь подготовили Вам подборку интересных вопросов и задачек с собеседований в ведущие IT-компании!


Выпуски будут появляться каждую неделю — следите за обновлениями! Рубрика выходит при поддержке рекрутингового агентства Spice IT.

На этой неделе мы собрали задачи с собеседований в американскую компанию PayPal. Кстати, ответы на задачки из прошлого выпуска уже опубликованы.

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


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

Ад менеджера

Исследование Лесли А. Перлоу 2017 года, опубликованное в журнале Harvard Business Review, показало: большинство менеджеров считают очные встречи неэффективными и мешающими их работе. Более того, продуктивность с каждой новой встречей уменьшается. В другом исследовании, опубликованном в том же журнале в 2022 году, было выявлено, что сокращение количества собраний на 40% может повысить продуктивность сотрудников на 71%.

Как же тогда вырваться из бесконечного числа встреч и переговоров и оптимизировать свой рабочий день?

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

Часто попадаются вакансии, где на первые строчки ставят не конкретные технологии, а понимание основ и skill set, которые способствуют успешному решению задач вне зависимости от знаний языков программирования, приложений и фреймворков.

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

Рассказывать айтишникам про психологию то еще дело, некоторые читатели скажут: «Bullshit!», и вообще не поверят, потому что психологию, даже прикладную, нельзя назвать точной наукой. Тем не менее, задача этой статьи — показать и доказать вам, что некоторые модели действительно работают. В основе доклад Сергея Котырева из UMI на РИТ++ 2017, от его лица дальше и пойдет повествование.



Я — IT-предприниматель с 20 летним стажем. Так получилось, что с самого начала карьеры мне пришлось управлять людьми. Как выпускник технического вуза и айтишник, я изначально понял, что люди сложно поддаются алгоритмизации, и вообще осознанию, пониманию и прогнозированию.

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

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

Часто можно услышать такие слова, как “впишется / не впишется в коллектив” в адрес того или иного разработчика. У кого-то это вызывает возмущение, у кого-то руки опускаются после очередного отказа на собеседовании или при внезапном увольнении. Да и с обратной стороны баррикад этот вопрос не дает людям покоя. А в последнее время на фоне всей этой ситуации с коронавирусом пошли слухи о массовых сокращениях и я решил поговорить немного на тему управления коллективом.

Задумывались ли вы, по каким принципам вы выбираете себе сотрудников? Кого нанять, кого уволить, кого перевести в другое место? Ну то есть помимо чисто технических знаний? Интуиция? Если да, то это как-то странно, должны же быть какие-то более систематизированные соображения на этот счет…

В сегодняшней статье мы посмотрим на 16 достаточно стабильных моделей поведения, типажей, которые позволяют разделить разработчиков на группы, и на которые вполне можно ориентироваться при принятии некоторых решений. Конечно, это все очень субъективно, но думаю, что кого-нибудь они подтолкнут к размышлениям. А это всегда полезно.

Гарри Клейн — американский психолог, исследователь интуитивных решений в экстремальных ситуациях. В своей книге «Источники силы» Клейн описал один случай: пожарная команда приехала вызов, в жилом доме горела кухня. Команда вошла в помещение и начала тушить огонь, но он не затухал. В какой-то момент командир почувствовал тревогу и приказал срочно уходить. Когда все вышли из дома, пол на кухне провалился. Оказалось, что пожар начался в подвале, а потом перекинулся наверх, поэтому погасить его на кухне не удавалось.



Позже Гарри Клейн опрашивал командира, чтобы собрать материал для книги и ему удалось разобрать его интуитивное решение на части: огонь на кухне был слабым, но при этом слишком много жара и дыма для такого пламени. Командир почувствовал, что ситуация опасная и вывел команду. Это пример «неявного знания», которое спрятано так глубоко, что оно проявляется только в реальной ситуации.

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

В последнее время возникает много обсуждений вынужденного удаленного режима работы для компаний. Один из наиболее интересных на мой взгляд вопросов: “Продолжат ли компании придерживаться удаленного режима или нет, когда вынужденный режим закончится?”.

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

Кроме этого, выстроенный процесс управления рисками ИБ позволит разработать и в случае необходимости применить чёткие планы обеспечения непрерывности деятельности и восстановления работоспособности (Business Continuity & Disaster Recovery): глубокая проработка различных рисков поможет заранее учесть, например, внезапно возникшую потребность в удаленном доступе для большого количества сотрудников, как это может произойти в случае эпидемий или коллапса транспортной системы. Итак, в этой публикации — анализ международных документов по управлению рисками информационной безопасности. Приятного чтения!