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

Сегодня мы будем проводить эксперименты на живых людях! Точнее, эксперименты уже проведены, и расскажет о них Анна, маркетолог и один из авторов Click.ru. До сотрудничества с компанией она проводила на себе эксперимент по тестированию популярных методик тайм-менеджмента. Итак, слово Анне.

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

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

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

Но на старте проекта (или при реформировании бизнес юнита) часто собираются новые команды. И в таких новых командах жизненно необходимо быстро и правильно построить методологию оценки задач; в ином случае, процесс планирования будет бесполезным, и даже примерно предсказать, когда будет сделана фича, станет невозможно.

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

Story Point (иногда Scrum Point) — относительная мера сложности или трудоёмкости элементов бэклога продукта.

Используется в Agile управлении продуктами.

Если отвечать утилитарно — оценки(Estimate) нужны для быстрого и реалистичного планирования объема работы на спринт и построения BurnDown (BurnUP) диаграммы или Velocity Chart.

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

Спешу сообщить: если вы не любите KPI, в вашей компании их просто не умеют готовить. Ну или вы разработчик. 

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

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

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

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

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

Привет всем!

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

P.S. Если автор что-то не разобрал и не написал, значит он посчитал это не обязательным в рамках этой статьи))) 

Для примеров будем использовать небольшую таблицу, которая показывает оценки учеников по разным предметам. В БД табличка выглядит следующим образом

В мире накоплено немало знаний о том, как вести проекты. Разработаны ГОСТы, стандарты, методологии и целые идеологии, которые говорят нам, что нужно сделать, чтобы прийти от идеи к результату. Нам остается только выбрать рекомендуемый путь и следовать ему.

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

Этот инструмент в широких кругах называется ТЗ – техническое задание. Еще он может называться спецификацией, user story, заданием или требованиями к разработке, суть одна – этот документ помогает нам прийти из точки A в точку B. Именно с такой позиции мы будем его рассматривать, независимо от формализации.

Но довольно банальностей! Перейдем к мясу.

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

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

Разработчику с проектированием и документированием решения задачи помогает аналитик.

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

Зачем придумали нотации (прим. система условных обозначений, принятая в какой-либо области)? Все просто, они помогают предотвратить много споров и конфликтов между людьми. Давайте посмотрим как BPMN (прим. Business Proccess Modeling Notation) нотация помогла нашим героям.

В некотором царстве, в некотором государстве жил был Царь и была у него мечта создать онлайн школу для обучения своих подданных. Созвал царь ученых со всего мира думу думать и решение предлагать. Три дня и три ночи трудились лучшие умы мира над решением задачи и вот предложили свое решение царю. И вот беда, Царь не понимает решений, один на иностранном языке все описал, другой непонятными символами. И говорит Царь: "Нет, братцы, так дело не пойдет, давайте-ка вы на одном языке мне все нарисуете, тогда я смогу выбрать лучшее решение!"

Царь предложил систему условных обозначений (нотацию bpmn) и обучил ученых как ей пользоваться.

Пост о том, зачем и как аккуратно вести проектную документацию, даже если у вас Agile. Делюсь перечнем и структурой полезных документов и рекомендациями по работе с ними.

Речь пойдет в основном о внутренних документах, которые обычно никто не просит писать, но которые на самом деле нужны команде.

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

Впервые прочитав эту цитату Кони Бюрера, который работал в Rational Software, я полагал, что корень всех проблем, возникающих при разработке ПО, кроется именно здесь. С тех пор я повзрослел, оброс шлейфом скепсиса и перестал писать код для продакшена. Я больше не несу ответственности за разработку, тестирование или поставку отдельных классов, компонентов и даже сервисов. Я отвечаю за максимально быструю и качественную поставку бизнес-ценности в рамках одного из ключевых бизнесов ЦФТ - сервиса денежных переводов Золотая корона.

Привет, Хабр. Меня зовут Ольга, я работаю в тестировании с 2013 года, специализируюсь на тест-анализе и тест-дизайне. Сегодня хочу рассказать, как при планировании тестирования сохранить фокус на пользователях и их потребностях.

Часто тестировщики начинают планирование тестирования с составления карты приложения. Т.е. формируют список страниц и перечисляют все контролы на странице. Это приводит к тому, что каждая страница сама по себе работает, но это не значит, что пользователь может выполнить свою задачу целиком. 

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

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

Мы GeekFactor. Вместе с GetMentor мы помогаем разработчикам найти работу за границей, а компаниям подбираем подходящих кандидатов.

Главные этапы в собеседовании зарубеж — подача резюме, system design interview, coding interview и culture fit interview. На что обратить внимание и как готовиться, мы расскажем в двух статьях. 

В первой мы поговорим о том, из чего состоит собеседование за рубежом, как составлять резюме и что нужно помнить, когда проходишь screening interview — разговор с эйчаром. Дополнительно обсудим, есть ли разница между CV и резюме, можно ли переехать джуну за 30, и как зарубежные компании смотрят на опыт в аутсорсе. 

Развитие информационных технологий привело к появлению бизнес-аналитиков.
Кто это такой? В чем его основные функции?
Кто был первым бизнес-аналитиком?

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