E-5

Блог E5

Заметки с передовой ИТ мира Украины ;)

  • Главная
    Главная Страница отображения всех блогов сайта
  • Категории
    Категории Страница отображения списка категорий блогов сайта.
  • Теги
    Теги Список тегов, используемых в блогах.
  • Блоггеры
    Блоггеры Список лучших блоггеров сайта.
  • Блоги групп
    Блоги групп Список лучших командных блогов.
  • Авторизация
    Авторизация Форма для авторизации
Последние записи блога

Early-bird-300x285У вас немає цілісної картини продукту?

   Прийшов новий проект, а ви не знаєте з чого почати?

      Не зрозуміло як організувати збір та аналіз вимог на проекті?

         Постійні розмови про те як повинен виглядати продукт, але немає спільного бачення?

             Те що розробляє команда в результаті нікому не потрібно?

Як ми вас розуміємо custom 4

Більше того, ми готові допомогти вам розібратись в цих нелегких питаннях на нашому воркшопі!

 

Як це буде? 
teacherВ форматі 7-годинного воркшопу, під часу якого ви:
- отримаєте основи управління вимогами в Agile
- дізнаєтесь про техніки створення та управління Product Backlog-ом
- навчитесь робити декомпозицію вимог від рівня Vision і до конкретної User Story 
- навчитесь вибирати найбільш затребуваний кінцевими користувачами функціонал
- подивитесь на процес розробки програмного забезпечення з позиції бізнес аналітика
- і звичайно на практиці спробуєте ці інструменти і наб’єте власні гулі custom 4

 

Коли? 26 березня  з 10:00 до 18:00 

Де? м. Київ, уточнюється

 

Вартість? 
early brid quite small Early birds до 10 березня 3900 грн 

EarlyBird small coffeeJust in time до 20 березня 4500 грн

itlogoLast call після 20 березня 5000 грн

  КУПИТИ КВИТОК

 

Цей workshop допоможе: 

yong

 Починаючому бізнес аналітику

- зрозуміти принципи роботи з вимогами на реальних проектах
- освоїти на практиці методики створення і пріоритизації проектної документації
- отримати досвід роботи по створенню вимог в команді
- отримати консультації та бачення досвідчених спеціалістів

 

 oldПрактикуючому бізнес аналітику::

- систематизувати інсуючі знання
- засвоїти нові практики роботи в Agile середовищі
- поспілкуватись та отримати консультації досвідченого практика  

 

 

coolПроектному менеджеру, тестувальнику, розробнику:

- розуміти чого варто чекати і які ставити вимоги до бізнес аналітика2B9A748F-DB5C-4A96-BE67-B0AD6343F07A bird
- навчитись самому створювати вимоги та розуміти процес роботи з ними 
- отримати основи нової професії!

 

Тренери:

Роман Сахаров  
має багаторічний досвід в ІТ, розробці програмних продуктів в різних ролях (QA, Business Analyst, Project Manager). Роман працює Business Analysis Manager i Delivery Manager в компанії EPAM Systems, а також є переможцем  Ukrainian IT Awards 2014 в номінації Business Analysis.

Прихнич Олена працює в IT більше 10 років, з них 9 на менеджерських позиціях. Прошла шлях від співробітника відділу підтримки до менеджера проектів та керівника офісу.
Займалась, окрім управління проектами, разробкою систем навчання та консалтингом. Проводить тренінги та коучинг по гнучким методологіям розробкименеджменту та мотивації.

  КУПИТИ КВИТОК

Просмотры: 1781
0

Добавлено : Дата: в разделе ITKaizenClub

BABA2 2

  • Ви бажаєте отримати цікаву та перспективну позицію бізнес аналітика, але не знаєте з чого почати?
  • Ви вже працюєте аналітиком або з вимогами (не називаючи себе аналітиком) щодня, але не впевнені чи правильно ви діїте?
  • Ви тільки плануєте перехід в ІТ, і бізнес аналіз здається вам найближчим по духу?
  • Ви плануєте створити свій власний продукт, але розгублені, бо не знайомі з процесом опису ідеї?
  • Ви зневірилися у тренінгах, які дають лише суху теорію, яка забувається на другий день?


Саме для Вас ми створили практичний курс Business Analysis Big Bang 2.0. Він відповість на безліч питань, пов'язаних з вимогами до програмного забезпечення та бізнес аналізом в ІТ, та проведе Вас по шляху від теоретичних знань до практичного використання аналітичних технік і світових практик.
Ми створили цей курс для того, щоб підготувати бізнес аналітика, який одразу ж по завершенню навчання зміг би почати успішну практичну роботу.
Цей курс наповнений лише тими техніками, які ми реально використовуємо самі в щоденній роботі, і які допоможуть вам впевнено виконувати бізнес аналітичні задачі на власних проектах, підтверджуючи свою репутацію професіонала.

 

Як це буде?


У форматі: теорія онлайн => домашнє завдання => практика офлайн => щотижневе тестування онлайн


лекції та практики, двічі на тиждень по 2 години ввечері
протягом 2 місяців та 19 занять (10 теоретичних, 8 практичних, +1 заняття з рекрутером)!
Стартуючи з 5 квітня 2016 (і перервою на Травневі)
Теорія по-понеділках о 19:00, практика середа, або четвер о 19:00 в районі м.Шулявська

  • Тільки перевірені та реально працюючі техніки бізнес аналізу,
  • Необхідна теорія, яку можна використовувати вже завтра
  • Практична робота на реальних прикладах
  • Можливість пройти всі етапи роботи аналітика, від визначення зацікавленних осіб до підтримки розробки, та самостійно підготувати всі найважливіші аналітичні документи
  • Домашні завдання та спільне обговорення результатів
  • Тестування ваших знань щотижня
  • Підготовка до співбесіди і поради щодо створення БА резюме від професіоналів - практикуючих бізнес аналітиків та рекрутерів з ІТ
  • Особистий підхід у кожній зустрічі

Наш курс допоможе:

 

  • Тим, хто ще не працює в ІТ, але дуже хоче потрапити і розуміє, що аналітичний склад розуму дозволить швидко увійти в професію
  • Тим, хто вже працює в ІТ, тестувальником, програмістам, інженерам підтримки и менеджерам, які розуміють, що бізнес аналіз це саме те, чим ви хочете займатись
  • Тим, кому важливі навички бізнес аналізу, і хто хоче чітко зрозуміти, як працює бізнес аналіз
  • Аналітикам, які бажають отримати бачення і практику бізнес аналізу в міжнародних компаніях та навчитися застосовувати світові практики


     

ЗАРЕЄСТРУВАТИСЯ  

Наші тренери:

 

Ірина Крючкова, бізнес аналітик в компанії Softserve з більш ніж 8-ма роками досвіду у бізнес аналізі. Співзасновниця Київської філії IIBA (International Institute of Business Analysis) і тренер.
Сертифікована, як CBAP (Certified Business Analysis Professional) i CSPO (Certified Scrum Product Owner).

Роман Сахаров, співзасновник компанії Е5, а також Business Analysist Team Leader i Project Manager в компанії EPAM Systems. Тренер і консультант в напрямку бізнес аналізу та гнучких методологій (Agile).
Переможець Ukrainian IT Awards 2014 в номінації Business Analysis, CSM (Certified Scrum Master).

 

Ціни та пакети:


 

  Онлайн лекції Онлайн лекції з офлайн практикою
Теоретичні основи бізнес аналізу та загально визнаних світових практик Так Так
Домашні завдання для вироблення практичних навичок бізнес аналізу
Так  Так
Відповіді на питання по домашнім завданням, рекомендації Так Так
Всі теоретичні матеріали пройденого курсу
Так Так
Додаткові матеріали для вивчення кожної теми глибше Так Так
Щотижневе тестування засвоєних знань Так Так
Кількість занять  
10 лекцій (онлайн)
+ 1 з рекрутером                  

 10 лекцій (онлайн)
8 практик (офлайн) 
+ 1 з рекрутером 

Практичні заняття в аудиторії на реальних прикладах
Ні Так
Групова перевірка домашніх завдань тренерами із загальними рекомендаціями Ні  Так
Практика використання найпоширеніших інструментів (засоби для спільнлї роботи, Visio, Balsamiq) 
Ні  Так
Готове портфоліо аналітичних документів, для представлення потенційним роботодавцям Ні  Так
Сертифікати Е5 про проходження курсу Так (електронний) Так (електронний та друкований)
Ціна, грн:    
Ранні пташки - до 05 березня  3000 10000
Вчасні пташки  - до 18 березня 4000 12000 
Пізні пташки - з 19 березня  5000  14000 

 

  ЗАРЕЄСТРУВАТИСЯ

 

Програма курсу


1. Вступ. Загальна інформація про процес розробки програмного забезпечення та місце аналітика і вимог в цьому процесі

a. Життєвий цикл розробки програмного забезпечення (SDLC)
b. Розподіл ролей в проекті по розробці програмного забезпечення
c. Визначення термінів "бізнес аналіз" та "бізнес аналітик"
d. Вимоги до програмного забезпечення, рівні вимог

2. Основна задача аналітика - спілкування та взаємодія із замовником (сommunication with client)

a. Знайомство, налагодження продуктивних відносин, підтримка контакту.
b. Початок аналізу - аналіз першопричин та аналіз зацікавлених осіб. Чому так важливо починати з визначення причин та зацікавлених осіб та як це ефективно реалізувати?

• Побудова карти впливу (impact mapping)
• Техніки аналізу зацікавлених осіб (stakeholders analуsis)

c. Виявлення вимог (elicitation) - щоденний аналітичний труд. Як робити цю роботу якісно та результативною?

• Етапи проведення процесу виявлення вимог.
• Техніки виявлення вимог: інтерв'ю (interview), мозковий штурм (brainstorming), спостереження (observation), семінари по вимогам (requirements workshops) тощо.

d. Продаж клієнту та навички презентації.

3. Створення аналітичних артефактів - документування вимог (documentation)

a. Документація різного рівня та формату: 

• Високорівневі вимоги: Бачення продукту (Vision), Документація бізнес вимог (BRD), Технічне завдання згідно різних шаблонів (в тому числі по ГОСТ), Тендерна документація (RFI, RFQ, RFP)

• Специфікування вимог: Історії користувачів (user story), Варіанти використання (use cases), функціональні та нефункціональні специфікації (functional, non-functional specification), специфікації вимог до програмного забезпечення (SRS) згідно різних шаблонів.

b. Моделювання вимог за допомогою UML
c. Прототипування інтерфейсу користувача (UI prototyping)

4. Взаємодія з командою розробки (сommunication with team) та підтримка розробки програмного забезпечення (supporting the development team)

a. Розбиття задач на складові (task breakdown, work breakdown)
b. Оцінка трудозатрат, необхідних на аналітичну роботу, та участь у оцінці трудозатрат на розробку (estimation)
c. Супровід щоденної роботи команди, робота в процесі розробки з клієнтом і командою
d. Управління змінами у вимогах (сhange management).

5. Постійний процес вдосконалення процесу бізнес аналізу та роботи бізнес аналітика (continuous improvement)

 

  ЗАРЕЄСТРУВАТИСЯ

Просмотры: 2525
0

b2ap3_thumbnail_-1_20151023-095333_1.png

В мире ИТ место и одна локация для всей команды – довольно редкая роскошь. Особенно если речь идет об аутсорсинге. Поэтому работать  в распределенной команде для нас стало столь естественно, что иногда вопрос «А как вы решаете проблемы при работе в распределенных командах?» вызывает ответный вопрос «А они правда есть?» Настолько часто наши команды бывают распределенными :)

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

Проблемы с коммуникацией. Не для кого не секрет, что большинство информации (по некоторым данным до 80%) мы воспринимаем через невербальное общение. Поэтому степень понимания задач, презентация заказчиком нового функционала и обсуждение архитектурных нюансов лучше всего происходят при физическом присутствии в одной комнате. Если же это не возможно, то постарайтесь организовать видео конференцию, где невербальные знаки будут хоть частично, но переданы. Кроме того, наличие видео помогает убрать стенку «они там» и «мы здесь», не дает демонизировать команду на другой стороне и помогает быстрее решать рабочие вопросы.  

Согласование общего времени работы, особенно если вы работаете в разных часовых поясах (не просто с Европой, где разница во времени несколько часов, а, к примеру с США или Индией или Китаем, где вам удастся поработать одновременно всего несколько часов в сутки). В таком случае любая прокрастинация любого члена команды с отправкой письма/звонка может спокойно вылиться в сутки простоя. Если разработчик ушел домой, решив – а напишу я вопрос завтра, а от ответа зависит как надо разрабатывать дальше функционал команде в другой локации, то очень реально, что всю первую половину дня задача будет просто заблокирована. Поэтому очень важно обращать внимание команды на цену откладывания любой коммуникации «на завтра».

Поддержание ощущения единой команды. Одном помещении мы часто болтаем за кофе/чаем, сидим за одним компьютером, когда что-то объясняем, и это происходит настолько естественно, что мы даже не замечаем этого. В распределенных же командах необходимо обязательно инициировать такое общение. К примеру, вводить парное программирование или код ревью, задействуя по одному человеку с каждой локации. Так же поощрять коммуникации ребят с заказчиком, обсуждения продукта напрямую, ни в коем случае не замыкая все на одном человеке. Даже если этот человек ПМ или бизнес аналитик :)

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

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

Визуализация работы. Если в одном офисе, когда работа кипит, то это просто банально видно – все что-то активно обсуждают, программируют, тестируют. Все стены завешаны диаграммами и мокапами, доски разрисованы схемами. То при работе в распределенных командах этого банально не видно, и необходимо всеми доступными способами визуализировать прогресс, особенно для начальства, которое вообще может быть в третьей локации. Здесь нам в помощь всевозможные трекинговые системы типа Jira, а также продуктивные совещания по обмену статусом. Ключевое слово - продуктивные :) Если честно, то в ИТ мире слово совещание или meeting иногда носит ругательный оттенок, т.к. «за совещаниями даже поработать не дают». Поэтому тут крайне важен баланс и постоянное держание фокуса: для чего мы собрались на этом совещании, какую проблему мы решаем, кто конкретно будет дальше заниматься этой задачей?

В заключении хочется отметить, что работа с распределенными командами это не только дополнительные проблемы, но и возможность узнать другую культуру и традиции. Ведь с индусами будут свои особенности работы, с американцами – другие, а с европейцами – третьи. Если первые редко когда говоря напрямую нет, вторые достаточно сильно задают темп "давай еще быстрее!", то третьи очень лояльны и темп проекта скорее будете задавать вы. И уделяя всего 2-3 минуты в начале общего звонка небольшим “small talks” о погоде, национальных праздниках и традициях, можно значительно улучшить отношения со своей второй половинкой команды :) Ведь не смотря на разные локации, у нас одна цель - сделать классный продукт ;)

 

Просмотры: 3681
0

Добавлено : Дата: в разделе Articles

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

1. Вызывать «вау!»-чувство нашим обслуживанием.

2. Принимать и поощрять изменения.

3. Создавать веселую и немного необычную атмосферу.

4. Любить приключения, творчески и нешаблонно мыслить.

5. Приветствовать рост и обучение.

6. Строить открытые и честные отношения посредством обмена информацией.

7. Создавать позитивный командный дух и семейную обстановку.

8. Делать больше меньшими средствами.

9. Быть увлеченными и решительными.

10. Быть скромными.

Zappos — это компания с удивительной корпоративной культурой, и ее особенности не ограничиваются списком, приведенным выше — таких «фишек» сотни, если не тысячи!

 

 

Просмотры: 3333
0

Добавлено : Дата: в разделе Articles

Мы продолжаем цикл статей об типичных ошибках в общении с заказчиками. Если прошлый раз мы говорили о «граблях» при интеграции с 3rd party системами, то сегодня поговорим об одинаковых словах с разным значением для разных людей. 

Common sense не существует... Или управление ожиданиями заказчика

Уверенны, у каждого из вас есть в прошлом не одна смешная и не очень история о том, что вроде-бы договорились, запустили в разработку, а на демо от заказчика слышишь:

- А такая-то функция где? 

- Как где, мы же и не должны были ее делать.

- Как не должны! В этой задаче и подразумевалось, что вы сделаете еще и 3-х уровневую проверку на валидность данных! 

b2ap3_thumbnail_-3.png

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

Думаю, уже многие потянулись в карман за рецептом в виде «Да пропишите же Definition of Done!». Действительно, толковый совет, особенно, если добавить Definition of Ready. Давайте же разберем эти 2 термина.

Definition of Done или же определение, что задача выполнена – это набор критериев, по которым мы определяем, что конкретная задача готова. В зависимости от компании, проекта и команды он может быть разным. 

К примеру, в некоторых проектах обязательным будет протестировать не только на QA, но и на UAT или же даже залить на Production. Где-то unit tests будут обязательными, как и code review другим разработчиком, а где-то – нет. Где-то нужно только вручную протестировать, а где-то и полностью покрыть авто тестами. 

Очень желательно обсудить ваш личный Definition of Done с командой, Product Owner/заказчиком, зафиксировать и переодически сверяться с ним в процессе разработки. 

Definition of Ready или же определение готовности – это набор критериев, которые обычно применяются к бизнес требованиям, к примеру, User Story. 

Очень рекомендую его обсудить и создать с командой и Product Owner/заказчиком. Особенно в случае, если у вас прослеживается тенденция брать сырые требования в спринт, в процессе выяснять все детали, и в результате не успевать все сделать в запланированные сроки. Сюда можно включать, к примеру, наличие соответствующих mock-ups/дизайна. Или же утвержденная схема реализации от архитекторов проекта. В некоторых проектах мы даже заводили отдельный статус для задачи – Groomed, который означал, что задача готова к тому, чтобы быть взятой в разработку и у разработчиков нет по ней открытых вопросов. 

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

 

Просмотры: 3645
0

Добавлено : Дата: в разделе Articles

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

Мы решили подойти к этому вопросу с долей юмора и описать интересные случаи с нашей проектной жизни. Как вы понимаете, все имена вымешлены, а совпадения – случайны ;) 

Дорогие мама и папа...Или как писать письма в 3rd party компании с техническим подтекстом рукой любимого Product Owner

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

 b2ap3_thumbnail_20150702-075236.png

"А здоровье мое не очень... то лапы ломит, то хвост отваливается. 

А на днях, я линять начал. Старая шерсть с меня сыплется, хоть в дом не заходи..."

Результат в виде обморока мамы и экстренного приезда был гарантирован.

Что же происходит в нашем дивном мире разработки программного обеспечения? Product Owner или человек, выполняющий эту роль, зачастую замыкает на себе коммуникации с представителями 3-х сторон и систем. Почему? Иногда из-за нежелания тратить время разработчиков на долгие обсуждения, иногда – по политическим причинам. К примеру, еси ваш заказчик всего лишь посредник и боится, что вы уведете клиента. Или по контракту он должен был все разрабоатывать сам, а отдал на аутсорсинг. А иногда – потому, что разработчики сами всеми силами избегают такого вовлечения.

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

И что, есть серебряная пуля? Конечно нет :) Но есть определенные рекомендации. 

Планирование. Как только вы узнаете, что планируется интеграция с какой-то подсистемой, попросите у своего Product Owner ее краткое описание, обсудите с командой/лидом потенциальные риски. Таким образом вы уже начнете прорабатывать риски. 

Живое обсуждение с технарями. Договоритесь о техническом обсуждении, на котором будут представилени этой системи и ваши технари. В идеале – живая встреча. Как минимум – звонок с возможностью расшарить экран. 1000 и 1 раз наталивались на то, чо даже общаясь на одном языке, все равно возникают недопонимания. Случай из жизни: интегрируемся с подсистемой, которую разрабатывали ребята из Германии. Мы посылаем запрос, а в ответ – тишина. Пишем письма – нам говорят – проблема на вашей стороне, у нас все работает. Делаем skype звонок, тот же диалог: 

- не работает!

- это у вас не работает, у нас все пашет!

И только когда мы попросили расшарить экран и продемонстрировать все – нашли причину. Она была в настройках фаервола :) Но по факту обе стороны были правы: у тех не работало, а у тех – работало. И припирание в письмах/звонках без демонстрации было пустой тратой времени.

Привлечение команды к составлению требований по итеграции. Ну это вообще классика :) Требование от Product Owner с описанием протоколов, технических нюансов и т.д., даже если у него/нее до это N лет опыта разработчиком, обязательно должны быть просмотрены командой. Даже если команда мега-занята и у них, как обычно, самая важная бага с прода и еще куча важных задач. Ибо им это воплощать в жизнь :)

В наших следующих статтях мы опишем другие интересные cases. Т.е. разберем альтернативные крабли. Coming soon ;) 

 

Просмотры: 3606
0

Добавлено : Дата: в разделе Trainings

 

Нещодавно ми проводили опитування щоб дізнатися, а що саме нас мотивує розвиватися і яким способом ми надаємо перевагу. Давайте подивимось на результати більш детально.

b2ap3_thumbnail_2.png  ЧИ РОЗВИВАЄТЕСЯ ВИ ЯК СПЕЦІАЛІСТ?

Ні, не вважаю за

                              Так, достатньо 11%             потрібне 1%      Ні, але вважаю, що треба більше 5%

b2ap3_thumbnail_22.png

Так, але вважаю, що треба більше 83%

 

  • Найбільша категорія які вважають, що розвиватися потрібно, але бачимо, що можемо більше та краще, таких було майже 83%.

  • Друга за величиною група, вважає, що вони достатньо розвиваються, таких було 11% і загалом це позитивний показник сучасного інформаційного простору, а можливо і освітніх ініціатив, які дають достатньо можливостей і в людей є досить мотивації цим скористатися.

  • Майже у два рази менше 5.4% виявилося тих, хто вважає, що не розвивається, але вбачає це важливим. Їм ми побажаємо часу, натхнення і можливості займатися саморозвитком, адже все у ваших руках. 

  • І тільки 1% людей вважає, що не розвивається і не вважає за потрібне.

Можливо, цей результат варто занести до статистичної похибки? :) 

 

b2ap3_thumbnail_4.png  ЯКІ ІНСТРУМЕНТИ ВИ ВВАЖАЄТЕ НАЙЗРУЧНІШИМИ?

У цьому питанні ми дізнавалися яким саме чином нам з вами зручно розвиватися, а які інструменти ми не використовуємо взагалі.  

b2ap3_thumbnail_nnnn.png

 

Тренінги - 28%  

Книги - 20%  

Вебінари - 16%  

Статті в Інтернеті - 22%  

Спільноти - 11%  

    Соціальні мережі  -  3%   

 

  

 

  • Тренінги виявилися найбільш популярними та ефективним способом отримання знань. І відповідно отримали найбільше кількість балів і голосів. Насправді, тренінги які дають змогу на практиці спробувати те чого вчать, природно вважаються найбільш корисними.

  • На другому місці, за середньою оцінкою опинилися Статті в Інтернеті, як самий простий та дієвий, на нашу думку, спосіб отримання інформації. І ми теж цілком підтримуємо цей погляд. Нікуди йти не потрібно, інформація може бути добре структурована і можна повернутися до неї у зручний час (де саме ми читаємо статті дивіться далі).

  • З мінімальним відривом у середній оцінці йдуть наші улюблені Книги! Вони дозволяють отримати повноцінне розуміння обраної теми. Їх також часто радимо на наших зустрічах.

  •  Четвертим за середнім балом, та першим за кількістю трійок опинилась, так звана, онлайн освіта або Вебінари. Вони, насправді, вимагають більш великої дисциплінованості і уміння концентруватися на тому, що відбувається на екрані впродовж декількох годин. Хоча, світові тренди вказують (тут і тут), що саме за онлайн освітою майбутнє, тож ми з вами зацікавленні в тому щоб навчитися сприймати і доносити правильно інформацію, саме у такому форматі. 

  • Що нас здивувало, це те що на передостанньому місці опинилися Спільноти, які дають змогу поділитися своїми проблемами і отримати нову інформацію. Така не найкраща оцінка пов'язана з тим, що порівняно з більш ІТ-розвиненими країнами наше середовище спільнот часто перебуває ще в початковому стані розвитку, але це не заважає спільнотам приносити користь і знання нам усім, які з більшою зрілістю сфери також ставитимуть кращими ( привіт нашому ITKaiZenClub)

  • І останнім з найзручніших інструментів виявилися Соціальні мережі, вони як за вагою так і за цінністю на  останньому місці. Можливо тому, що це не зовсім інструмент для отримання знань, а скоріше як засіб ї транспортування чи донесення. 

    b2ap3_thumbnail_9_20150616-105454_1.png


 Як висновок, можемо сказати, що погляди в опитуванні збіглись з тим, що ми спостерігаємо на практиці. Кількість відвідувачів і охочих відвідати живі тренінги значно більша і популярність таких заходів виправдана їх ефективністю. Але для себе ми зробили висновок, що можемо і маємо продовжувати ділитись (а може й писати) з вами цікавими статтями, які допомагатимуть вам у розвитку,  оскільки саме статті - є дуже важливим джерелом.

 

b2ap3_thumbnail_5.png  ЗВІДКИ ВИ ДІЗНАЄТЕСЯ ПРО ТІ ЧИ ІНШІ СПОСОБИ?

  b2ap3_thumbnail_70_20150616-182038_1.png Альтернативні джерела:

stackoverflow.com
software-testing.ru
4qa.by
utest.com
techrunch.com
thecommunitymanager.com
coursera.org
analyst.by
marketingland.com
searchengineland.com
inc.com
mirknig.com

  • Першим, виявився усім відомий ресурс Habrahabr.ru. Як головний ресурс певно всього СНД та пострадянського простору. Насправді недарма перебуває в лідерах, так як кількість хороших авторів і різноманітність тематик задовольнить більшість прагнень

  • Другим, з трішечки меншою кількістю оцінок (-10) йде наш улюблений і Український Developers.org.ua (також відомий як dou.ua ). З дещо вужчою тематикою ніж хабр, доу залишається лідером на Українському просторі ІТ ресурсів. Цікаві огляди і лідери думок обирають саме доу, на якому можна почути і зрозуміти всі останні віяння і болі Української сфери ІТ (а часом і держави :) ). З нашого досвіду, також багато з наших шанувальників дізнаються про події саме з доу календаря.

     

  • На третьому місці, опинився Facebook, як місце де зручно можна підписатись на цікаву групу і отримувати оновлення по цікавим темам. Нічого більше сказати не маємо, тільки те, що до нас приєднується все більше людей на фейсбуці і саме там найлегше спілкуватись нам з вами :)

  • Далі йде Ain.ua який зайняв четверте місце, портал активно розвивається і став улюбленим місцем для поціновувачів стартапів і інтернет-бізнесу як такого. Особисто рекомендуємо )

І трійка замикаючих в нас очолює соціальна мережа для професіоналів Linkedin.com, за ними йдуть інші варіанти (див. графік нижче) з варіантами у яких було декілька голосів, найбільше голосів виявилось у друзів та колег і у нашого шановного Google.com:) І замикає наш ряд vk.com, тут нічого додати.

 

b2ap3_thumbnail_8.png ЩО СПОНУКАЛО Б ВАС ВКЛАДАТИСЬ У СВІЙ ПРОФЕСІЙНОЙ РОЗВИТОК БІЛЬШЕ?

У цьому питанні ми хотіли зрозуміти, що саме спонукає нас розвиватися.

b2ap3_thumbnail_11.png

  • Першими виявилися, очікувано - чіткі кар'єрні перспективи, тобто розуміння того, що наше навчання приведе до підвищення кваліфікації, позиції і дозволить просунутися вперед, до більш цікавих проектів, цікавіших завдань (це ми запитаємо у наступному опитуванні)

  • Другою причиною стала фінансова мотивація, яка звичайно дозволяє не думати про клопоти, зосередитися на роботі, або правильному відпочинку у відповідний час, не задумуючись чи вистачить на все грошей

  • звичайно, цікавість нашої роботи важлива і розвиватися ми теж прагнемо у тому, що нам цікаво, а можливо і популярно. Відповідно третє місце. 

  • На четвертому місці, з невеличким розривом йде визнання мого розвитку, яке у великій мірі перекликається з першими двома питаннями, та все ж таки більш сконцентроване на тому чи важливі речі ми робимо чи потрібні вони оточуючим.

  • І на останньому місці опинилась загроза втратити кваліфікацію, що теж доволі логічно, оскільки більшість опитаних займаються професійним розвитком і втрата кваліфікації на такому ринку не така й проста:)

     

b2ap3_thumbnail_12.png НАШІ РЕСПОНДЕНТИ

Не обов'язковим для заповнення питаннями були місто і посада. Активність нашої аудиторії навряд чи дає змогу судити, про ту чи іншу ІТ активність у згаданих містах, але можливо ми з часом придумаємо як вона корелює з іншими результатами.a1sx2_Thumbnail1_Ukraine.png

І останнє, це ті хто заповнив опитування. Найбільше виявилося проектних менеджерів, далі майже рівними кількостями - бізнес аналітики, розробники та QA/ Вибірка виявилась досить цікавою.

 

a1sx2_Original1_people1.png

 

b2ap3_thumbnail_10.png

  Для нас опитування було цікаве, перед усім спілкування з вами, а також розуміння того які головні ресурси використовуються для навчання. Сподіваємося, наша статистика буде цікава і вам, і ви дізнаєтеся щось нове або мінімум підтвердите свої здогадки.

  Діліться своїми думками у коментарях:)   

Просмотры: 12397
0

Добавлено : Дата: в разделе Trainings

 

Шановні колеги та друзі! На зустрічах ITKaizenClub, під час тренінгів та вебінарів ми часто розповідаємо про гнучкі методології Agile і про те як ефективно працювати у їх середовищі. Але багато для кого Agile, та зокрема, Scrum залишаються казкою на сторінках статейта книг, багато питань залишаються без відповіді. Тож у нашому курсі "Scrum Fundamentals" ми вирішили структурувати ключові поняття Agile та Scrum.

 

 

 

 

b2ap3_thumbnail_0.png

 

 

Шановні колеги Ми поділимося своїм досвідом та дамо вам повну картину того з чого повинен складатися Scrum.

Це буде корисно і дасть вам необхідні знання для роботи в середовищі Agile та Scrum, а також дасть можливість запровадити Scrum у вас на проекті та отримати всі переваги роботи в Agile середовищі.

Наш курс буде складатися з 10 модулів:

   Розділ 1: Scrum для члена команди

     -Модуль 1. Вступ до Agile та Scrum 3 березня

     -Модуль 2. Scrum команда 10 березня

     -Модуль 3. Вимоги у Scrum 12 березня

     -Модуль 4. Оцінка та продуктивність 17 березня

   Розділ 2: Scrum для Scrum master

     -Модуль 5. Планування Спринту та Релізу 19 березня

     -Модуль 6. Моніторинг Спринту 24 березня 

     -Модуль 7. Постійне вдосконалення 26 березня

   Розділ 3: Просунутий Scrum для менеджера проектів/програм

     -Модуль 8. Масштабування Agile 31 березня 

     -Модуль 9. Agile mindset або що таке "Гнучкий світогляд" 2 квітня 

     -Модуль 10. Типові помилки при впровадженні Scrum 7 квітня

Кожна тема - це вебінар тривалістю 1-1,5 години, де ми не лише поділимоя теоретичними знаннями та практичними інструментами для впровадження у вашому проекті, але й відповімо на всі ваші питання. 

Всі теми доступні у записі, тож ви зможете їх переглянути у зручний для себе час. 

Тренери: 

Роман Сахаров, CSM, Agile PM i BA 

Альона Прихнич, ICAgile Certified, Senior Scrum Master, Agile PM

Кожен учасник курсу, по-закінченню отримає сертифікат компанії Е5, що підтверджує проходження курсу.

   Купити квиток

Тож приєднуйтеся до нашого курсу й отримайте практичні інструменти для впорядкування ваших проектів вже зараз!

Просмотры: 13284
0

Добавлено : Дата: в разделе Trainings

Шановні колеги та друзі!

До нас частенько приходять з питанням на тему бізнес аналізу і цікавляться про те в  чому саме полягає робота бізнес аналітика та як ним стати. Тож ми вирішили допомогти усім зацікавленим і створили серію вебінарів які розкажуть і пояснять чим і як займається бізнес аналітик, і звичайно дадуть вам базу для розвитку бізнес аналітичних навичок у собі. Оскільки навички роботи з вимогами потрібні не тільки аналітикам, але й розробникам, тестувальникам чи проектним менеджерам.  

a1sx2_Thumbnail1_ba-advert_red.jpg

Курс складатиметься з шести вебінарів і покриє головні аспекти відповідальності аналітика і власне процесу роботи з вимогами. Що важливо - проходитиме у зручний для всіх післяробочий час. А більше деталей ви знайдете у кожному описі вебінару , де й зможете зареєструватися.

Частина 1: Робота з замовником, бізнес вимоги

Частина 2: Старт проекту та аналітичної фази

Частина 3: Опис та деталі продукту

Частина 4: Аналітик у фазі побудови продукту

Частина 5: Комунікації аналітика

Частина 6: Кар'єрний розвиток аналітика

Ну і звичайно, оптом дешевше:) Тому хто купить одразу всю серію вебінарів - один у подарунок!

Реєстрація для всіх і одразу - ТУТ 

До зустрічі на вебінарах!

Команда Е5

Просмотры: 4252
0

Добавлено : Дата: в разделе Trainings

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

 a1sx2_Original1_e-5-knowledge.jpg

Вебинар "Как стать менеджером в ИТ" 22 октября

Вебинар "Мотивация сотрудников" 28 октября

Вебинар "Делегирование, постановка и контроль задач" 30 октября

Вебинар "Обратная связь сотрудникам: как, когда, зачем?" 04 ноября

Вебинар "Жизненный цикл команды" 06 ноября

Вебинар "Тайм-менеджмент" 11 ноября

Вебинар "Управление рисками" 13 ноября

Для тех, кто захочет все и сразу - у нас подарок ;)

При оплате всего курса 1 вебинар (любой на ваш выбор ;)) - бесплатно!

Закажите свою прорцию знаний ;) 

До встречи на вебинарах ;)

Команда Е5

Просмотры: 2832
0

Добавлено : Дата: в разделе Trainings

Одесса как праздник – теплый, душевный, со своим юмором и колоритом. Поэтому возможность поехать на конференцию для менеджеров проектов и провести воркшоп по управлению требованиями на Agile проектах в рамках Odessa Innovation Week была встречена радостным «Да! Да! Да!»

b2ap3_thumbnail_10511651_738104889585059_3297229914030491277_o.jpg

Те доклады, на которые мне посчастливилось попасть радовали огромным практическим опытом докладчиков. Если о новых веяниях в индустрии ИТ немного умалчивали, то вот практических советов о том как правильно мотивировать ИТшников, организовывать работу команд – распределенных или тех, которые сидят вместе, какие типичные ошибки при внедрении Agile и как их избежать, а так же про правильную организацию управлением требованиями на Agile проектах, говорили много и по делу. Именно последнее меня и радовало – синтезированный практический опыт с конкретными советами! Думаю вы без труда найдете соответствующие видео записи в скором времени на сайте организаторов ;)

b2ap3_thumbnail_10552409_274958549372338_421823782499162510_n.jpg

Самое интересное, что не смотря на то, что на вопрос «Кто из вас слышал об Agile?» поднял руки весь зал, на вопрос «А кто по нему работает?» - только половина, то вопрос «А кто из вас слышал о технике story mapping?» показал, что о ней слышало лишь 3 человека, один из которых – Agile коуч J То ли остальные хранили тайное знание то ли эта тема все еще подлежит более глубокому изучению нашим ИТ сообществом ;)

А второй день был посвящен оттачиванию навыков участников. Мы с командой сосредоточились на Управлении требованиями на Agile проектах. Не смотря на одесский ливень, который устроил целый потоп, наш воркшоп состоялся! Команда подобралась не простая: были как и представители бизнеса (приятно, что бизнес понимает важность и необходимость правильного управления требованиями ;)), так и менеджеры проектов и тим лиды. Наверное, поэтому вопрос о пользе для конечного пользователя и его важность были поняты сходу. Надо признаться, это значительно ускорило сам процесс обучения. Правда, с другой стороны, выплыл вопрос «common sense», т.е. это и так же понятно, зачем его описывать? J После бурных дискуссий и прохождения всех кругов разбивки требований у ребят выкристоливался целый релиз план их нового продукта!

a1sx2_Thumbnail1_10402518_274958562705670_323750300118807104_n.jpg

Надеемся, вскоре мы увидим его на нашем рынке ;) А пока - еще фоточки ;)

Просмотры: 2326
0

Чарівним суботнім ранком, коли більшість з нас ще отримувала насолоду від чергового вихідного, дехто з наших колег вже поспішав з самого ранку у офіс Cogniance з величезним прагненням здобувати нові знання. А тим часом команда Е5 активно готувалась провести Воркшоп на тему управління вимогами в Agile проектах.

Після теплого знайомства й філіжанки запашної кави розпочався fun! Перед усім ми домовились, що усі техніки повинні використовуватись з розумінням та обов’язково адаптовуватись під потреби проекту (див. Agile has no brain… :)

Важливим моментом будь-якого тренінгу по вимогам є однакове та правильне розуміння того, що є для нас вимогами та як вони виникають в головах Product Owner-ів і Product Manager-ів.  А головне - як вимоги різних рівнів вибудовуються у логічний ланцюжок, пов'язуючи бізнес цілі з потребами користувача і  функціональними вимогами продукту. Саме ці принципи ми одразу й почали практикувати, створюючи Vision документ для соціальної мережі нашої мрії. Треба віддати належне командам, їх ідеї були дуже цікавими, та захоплювали настільки, що вони всерйоз задумувались над реальним втіленням своїх ідей ;)
a1sx2_ThumbnailLarge_10500584_270373286497531_1634899539939758244_n.jpg
Після креативних презентацій власного бачення соціальних мереж, ми з командами одразу ж перейшли до деталізації успішно використовуючи техніку User Story Mapping, яка дозволила нам отримати спільний погляд на продукт, виділити в ньому головні напрямки і упорядкувати за User Journey (тим як користувачі стикаються з функціоналом по мірі використання продукту). Сама техніка захопила нас як своєю упорядкованістю так і тим що вона заохочує кожного вкладати своє бачення в кінцевий продукт і прибирає можливість нав'язування чиєїсь думки на етапах продумування функціоналу.

Оскільки жодна розробка не обходиться без пріоретизованого списку того, що нам потрібно створити, ми поговорили про те які саме головні характеристики Product Backlog, з чого він складається, як його правильно сформувати і забезпечити відслідковуваність вимог.
a1sx2_Thumbnail1_10526036_270372869830906_957144228940404086_n.jpg
User Story - доволі поширена техніка і для багатьох учасників не нова, але, розглянувши принцип INVEST, у наших учасників з'явилось більш чітке розуміння того як саме правильно створювати історії користувача, та почали усвідомлюватись типові помилки, які допускались на роботі. А далі на нас чекало шалене створення User Story, базою для яких був вже зроблений Story Mapping. І це логічно продовжило роботу над омріяною соціальною мережею.
І на сам кінець ми розглянули, що таке Acceptance Criteria, як їх правильно створювати і зробили їх для наших  User Story.
Під кінець, стомлені та щасливі, з чіткою картиною того, як перетворити загальну ідею у конкретні завдання розробникам, наші учасники пішли втілювати в реальному житті проекти своєї мрії :)
Тож чекаймо на просторах України та світу нових, унікальних та потрібних соціальних мереж, адже вимоги для них вже створені!

a1sx2_Thumbnail1_10504951_10204515197227007_156636876217570194_o.jpg

Тож, до наступних зустрічей у захоплюючому світі розробки програмного забезпечення! А поки - наші світлини!

Просмотры: 2491
0

Добавлено : Дата: в разделе ITKaizenClub

Хотим с вами поделиться историей про овечку по имени Ламо.

b2ap3_thumbnail_proxy.imgsmail.ru1.jpg

Когда ему было 3 месяца, его сбила машина. Ламо приютила женщина - Дженнифер Джонс. Она взяла его к себе и Ламо, стал расти с 3 собаками Дженифер. Результат был потрясающим - Ламо стал себя вести как обычная... собака! Привычки у животного больше подходят собаке, чем овце: он приносит хозяйке палочки и мячики, носит ошейник, подпрыгивает на задних ногах и пытается лаять,

Дженнифер часто берет Ламо с собой, когда идет в гости к друзьям — пока она с ними общается, барашек "стрижет" газоны. Также Ламо нравится кататься в фургоне и он с удовольствием плавает  даже ныряет.

К чему мы это все? Конечно же, к нашему окружению!

По мнению ученных человек на 50% копирует свое окружение в поведении. Остальные наши действия на 40% состоят из нашего мышления и лишь на 10% из знаний.

b2ap3_thumbnail_proxy.imgsmail.ru.jpg

Это еще раз доказывает, как важно общаться с людьми, у которых есть те знания и навыки, которые вы хотите приобрести в ближайшем будущем. Поэтому не откладывайте в долгий ящик общение со своими коллегами ;) Одна из возможностей это сделать - посетить наш ITKaiZenClub ;) 

Просмотры: 2114
0

Добавлено : Дата: в разделе ITKaizenClub

10 июля сообщество менеджеров в ИТ и всех, кого интересовала тема корректных увольнений собралось для обсуждения и деления опытом.

b2ap3_thumbnail_ITKaiZenClub_Presentation.jpg

Вместе с замечательным HRManager @ Wargaming– Ириной Радченко мы начали путешествие в этот не простой мир управленческих решений.

b2ap3_thumbnail_10423946_269738906560969_2279338902907204785_n.jpg

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

Вовремя уволенный сотрудник – это не нанятый кандидат !

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

От сюда настоятельные рекомендации:

  • уделяйте должное внимание найму сотрудника, перепроверяя его как технические, так и softнавыки, насколько он сможет вписаться в вашу команду;

  • привлекайте/активно интересуйтесь мнением рекрутера касательно кандидата. Зачастую рекрутеры/HRменеджеры и психологи, которые смогут дать вам свое виденье психотипа кандидата и его softskills.

b2ap3_thumbnail_10483235_269738916560968_5107452549348633757_n.jpg

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

Если вы столкнулись с похожими проблемами, настоятельно, рекомендуем:

  • Не игнорируйте проблему. Как показывает практика, обычно не «пронесет», не «рассосется» и не становится лучше.

  • Если есть возможность/необходимость – обсудите ситуацию с вашим руководителем/HRменеджером. Они не только смогут дать вам полезные советы, но и подстрахуют на случай непредвиденных событий.

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

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

    b2ap3_thumbnail_10509738_269740306560829_8401998028573237422_n.jpg

Вы не увольняете сотрудника просто потому, что у вас такое сегодня настроение…

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

Тут важно отследить следующие моменты:

  • Есть объективные факты не выполнения сотрудником своих непосредственных обязанностей.

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

  • Вы проконсультировались с вашим руководителем/HRменеджером относительно текущей ситуации.

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

b2ap3_thumbnail_10394630_269740333227493_2908646006018981833_n.jpg

Как увольнять корректно?

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

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

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

  • Соберите «Рюкзак увольняемого». Это может быть любой сувенир на память о компании и/или вашем проекте: футболка с фото с корпоративов/тренингов, чашка, рамочка с любимой фразой заказчика – экспериментируйте и креативьте. Здесь важна не цена, а эмоциональная составляющая, ведь негатив со временем забывается, а положительные впечатления останутся как плюс к имиджу вашей компании. ·

  • Проведите Exit-интервью. Обычно оно делается на этапе когда все бумажки подписаны, а пропуски сданы. Лучше всего если его проводит HRменеджер. Цели у такого интервью как минимум две:

    • Выяснить взгляд на проблему со стороны увольняемого. На этапе когда никто уже ни перед кем не отчитывается могут всплыть новые интересные факты ситуации.

    • Убрать негативные эмоции сотрудника. Увольнение вещь малоприятная, поэтому давая сотруднику возможность высказать все и вся вы уменьшаете вероятность того, что он это сделает где-то на DOU или каком-то альтернативном ресурсе.

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

b2ap3_thumbnail_10534150_269740443227482_2843897335878454435_n.jpg

Лучший способ борьбы со слухами – официальная версия ;)

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

Поэтому стоит работать на опережение и сказать всей команде на очередном собрании вашу версию происходящего: ·

  • Очень желательно убрать эмоции и в сухом остатке прокомментировать ситуацию, делая упор на рабочие моменты.

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

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

А как надо?

b2ap3_thumbnail_pic1.png

Также мы бы хотели несколько слов сказать о “must have” для менеджера – те практики, которые необходимо выполнять в своей повседневной работе, чтобы не приходилось увольнять/увольняться сотрудникам :)

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

Во-вторых, one-to-oneвстречи – наше «все». Именно на регулярных встречах вы и будете узнавать насколько ваш сотрудник доволен своей работой, положением дел на проекте с его точки зрения и возможных проблемах. Мы настоятельно рекомендуем добавить эти встречи в календарь и не пропускать. Оптимальная частота one-to-one встреч зависит от проекта/конкретного менеджера и сотрудника. В среднем же рекомендуем проводить их раз в 2-4 недели.

b2ap3_thumbnail_10435679_269740346560825_3949066036802024605_n.jpg

В-третьих, обязательно своевременно давайте обратную связь сотрудникам. Об этом все знают, но не все делают. Если вы выдите, что что-то поменялось на проекте, не ждите очередной one-to-one встречи – поговорите с сотрудником незамедлительно. Аналогично не надо ждать пол года, чтобы дать обратную связь по продуктивности/профессионализму сотрудника – воспользуйтесь регулярными one-to-one.

В-четвертых, своевременно выявляйте изменение мотивации у ваших сотрудников. Все мы люди, если вчера сотрудник мог кодить ночи на пролет, то завтра у него изменится семейное положение и он захочет более гладкого графика. One-to-one– отличная возможность держать руку на пульсе ;)

Ну и в-пятых, не игнорируйте, а вовремя вскрывайте и решайте конфликты в команде. Так вы отделаетесь всего лишь «лекгим испугом» ;)

b2ap3_thumbnail_10553622_269740463227480_3054410930923935389_n.jpg

Надеемся, наши советы будут вам полезны. Детальная презентация тут :) Если возникнет желание поделиться своими кейсами/практиками – мы будем очень благодарны! Следующая наша встреча 29 июля!

Ну а больше фоточек на нашей страничке в FaceBook ;)

Привязка к тегам fire ITKaiZenClub Project management team
Просмотры: 3203
0

Добавлено : Дата: в разделе Trainings

С пятницей вас!

В предверие у нас много всего замечательного!

Сегодня, 27 июня вся Украина празднует День вышиванки. Многие ИТ компании уже запестрели свежими фоточками в вышиванках в соцсетях.

Завтра мы все будем праздновать День конституции, в связи с чем понедельник – приятное дополнение к выходным! А еще День молодежи, в связи с чем города наполняться всякими концертами и мероприятиями на любой вкус и цвет ;)

Мы решили сделать что-то приятно-полезное для тех, кто постоянно обучается!

b2ap3_thumbnail_birds-and-present.jpg

Мы дарим билет на наш Workshop «Управление требованиями на проекте: от идеи к работающему продукту» тому, кто:

1) Залайкает нашу страничку в Facebook

2)  Поделится нашим постом у себя на страничке

Результаты розыгрыша будут оглашены во вторник, 1 июля на нашей страничке в Facebook.

b2ap3_thumbnail_birds-1-.jpg
А для тех, кто хочет полагаться на себя, а не на волю Фортуны, напоминаем, что 30 июня заканчиваются
early birds билеты. Спешите зарегистрироваться по самой выгодной цене ;)

 

 


И...(барабанная дробь) счастливчиком стал Юрий Щербина, с чем его сердечно поздравляем, он получает билет на воркшоп бесплатно! Верим, что участие даст Юрию много новых и полезных идей по управлению требованиями на своем проекте! 

билет на воркшоп

Просмотры: 1593
0

Сегодня команда E5 делилась опытом и знаниями с невероятными ребятами на конференции Software Engineering 2014. Конференция организована специально для молодых ребят и девушек, которые хотят дальше развиваться в мире ИТ.

b2ap3_thumbnail_IMG_3731_small.jpg

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

Мы прошлись по методологиям создания требований, рассмотрели как это происходит в Agile. Детально рассмотрели такие базовые понятия как User Story, Product Vision, Theme, Epic и управление Product Backlog.

b2ap3_thumbnail_IMG_3729_small.jpg

Особо полезными были техники приоритезации требований и фич MoSCoW и практика, по которой бизнес-аналитик может проверить качество своих требований - соответвие принципам INVEST.

Суть техники MoSCoW заключается в том, что вы разделяете все функции продукта (или любого другого списка, который вам необходимо приоритезировать, к примеру – ваши дневные задачи) на категории:

  • M - MUST
  • S - SHOULD
  • C - COULD
  • W - WON'T (but would like)

Далее работаете с категориями Must & Should, а категорию Wont вообще исключаете из разработки. Таким образом вы будете концентрироваться исключительно на самых важных частях продукта, а неважные не попадут в разработку, сэкономив ваш бюджет.

Ибо, как утверждает исследование Standish Group, более 64% функционала програм используются редко или не используются вообще.

b2ap3_thumbnail_screen.jpg

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

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

b2ap3_thumbnail_IMG_3722_small.jpg

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

Если честно, то мы совершенно не ожидали, что после завершения доклада мы еще почти столько же времени проведем, отвечая на вопросы и общаясь с невероятными ребятами :) Это было безумно классно!

Тем более, что у нас были подарки ;) Мы подготовили типичные шаблоны документов и интересную книгу в награду за самый интересный вопрос.

b2ap3_thumbnail_1.png

Когда пришло время вручать книгу, наши мнения разделились между 2 вопросами:

1) Какие ваши персональные Epic fails в вашей карьере?

2) Если у нас (пост-советская молодежь) есть потенциал, то почему мы так равняемся на запад?

В результате бурных дискуссий книга Ключевые цифры Д. Маекса стала достоянием Anna Vaselkova 

Искренее надеемся, что чтение будет приятным и полезным ;)

Если вы пропустили доклад, мы с радостью поделимся с вами нашей презентацией!

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

До встречи на просторах интересного мира информационных технологий ;)

Команда Е5

 

 

 

Просмотры: 5217
0

Добавлено : Дата: в разделе ITKaizenClub

Мне кажется тема "team building" такая же вечная, как и тема менеджмента и лидерства. Ее актуальность будет в силе пока люди собираются вместе, чтобы что-то создать, и не важно по каким причинам. Пока есть общие цели и желание их достичь, люди снова и снова будут возвращаться к ней. 

Одной из разновидностей этой темы является тема самоорганизовывающейся команды.

С одной стороны, Agile принципы говорят нам о том, что команда должна быть самоорганизующейся, и именно такую команду берут за основу всем известные Scrum/KanBan/ScrumBan. Но, с другой стороны, на практике постоянно сталкиваешься с тем, что задача не берется первым освободившимся, идут blame-games, ребята просто отсиживают от звонка до звонка и ни о какой проактивности речь вообще не идет.

"Так в чем сила, брат?" :)

Именно с этим мы и разбирались на июньской встрече ITKaiZenClub 3 июня 2014 года :)

 

b2ap3_thumbnail_IMG_3686_small.jpg

Начнем, пожалуй, с обращения к истокам, т.е. к принципам Agile и тому что в них говорится о командах.

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

Т.е. как видим самоорганизовывающиеся команды являются одним из ключевых аспектов, на которых базируется Agile разработка.

Какие же основные признаки самоорганизовывающейся команды? Мы выделили следующие:

b2ap3_thumbnail_pic1.jpg

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

Далее мы «похоливорили» на тему command and control VS самоорганизовывающиеся команды. Как известно, идеального решения нет. Как command and controlтак и self-organized team могут применяться в зависимости от вашей ситуации, а с любыми крайностями необходимо быть осторожным.

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

b2ap3_thumbnail_IMG_3687_small.jpg

Кстати, самоорганизовывающаяся команда – это не вид менеджмента :) Это скорее попытка охаректиризовать тип команды и систематизировать критерии. Спасибо за это важное дополнение нашим участникам ;)

Теперь давайте ответим на вопрос: а как же создать эту самую самоорганизовывающуюся команду?

b2ap3_thumbnail_pic3.jpg

Или же кратко, можем выделить 5 основных шагов:

Step 1: Set the common goal

Step 2: Establish knowledge-sharing environment & provide feedback

Step 3: Give each a bit of authority. Help team to resolve conflicts and come up with decisions

Step 4: Let team decide

Step 5: Set “good” metrics

 

На последок вернемся к Agile практикам и посмотрим, насколько они помогают или наоборот, противоречат построению самоорганизовывающейся команды:

b2ap3_thumbnail_pic2.jpg

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

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

 

b2ap3_thumbnail_IMAG0721.jpg


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

С нетерпением ждем вас на нашей следующей встрече ITKaiZenClub!

Команда Е5

b2ap3_thumbnail_IMG_3691_small.jpg

 

Привязка к тегам ITKaiZenClub Project management team
Просмотры: 7845
0

ITKaizenClub начал свою жизнь "в реале"

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

b2ap3_thumbnail_IMAG0658_20140523-183252_1.jpg

Сначала Прихнич Алена осветила наболевшее :)

  • Как работать с командой в условиях стресса и почти-военного положения?

  • Как успокоить заказчика?

  • Как самому отрезвится по поводу ситуации в стране?

b2ap3_thumbnail_IMAG0660.jpg

А потом Сахаров Роман рассказал, как пошагово создать свой план для обеспечения Business Continuity Planning.

b2ap3_thumbnail_10268429_10203850338245948_4917103232002476974_n.jpg
13 простых шагов, которые позволят вам продолжать жизнедеятельность вашего бизнеса при наступлении форс-мажорных обстоятельств.

b2ap3_thumbnail_1017761_241570539377806_7252535890430216688_n.jpg

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

 

Ждем вас на нашей следующей встрече!

Следите за нашими новостями по тегу #ITKaiZenClub

 

Привязка к тегам ITKaiZenClub Project management Risk management
Просмотры: 1627
0

Что может быть приятнее весеннего солнышка, распускающихся деревьев и свежего морского воздуха?

b2ap3_thumbnail_IMAG0615.jpg

Конечно же возможность совместить приятную поездку с познавательной конференцией по продажам в ИТ!

b2ap3_thumbnail_IMAG0622.jpg

Для нас было открытием, что в Украине столько фирм на профессиональном уровне занимаются продажами ИТ аутсорсинга за рубеж! Уровень докладчиков, их рассказы очень обнадежили :) 

К примеру, Анастасия Новикова из Conformato в своем докладе "Продажи по телефону: кому и как звонить, а главное - что продавать?" дала детальные рекомендации по "холодным" звонкам: как перебороть страх и нежелание звонить, как вести разговор, а главное - поделилась своей статистикой, согласно которой откровенно грубо ей отказывали всего лишь раз :)

    b2ap3_thumbnail_IMAG0621.jpg

"Продажи в B2B стартапе" от Никияры Пурмамбетовой из UCat вселили веру в будущее :) Внедрить электронный документооборот в таких гигантах как Нестле - респект и уважуха :) О том как они это делали и с какими проблемами столкнулись Никияра и рассказывала в деталях.

Отдельно мы ждали доклада от COO Kuadriga "Як вижити в умовах багряного океану аутсорсингу в Україні?" - Натальи Стоянович. Она рассказала как они с партнером выстроили аутсорсинговый бизнес, выростив компанию с 2 до 100 человек за 5 лет. При этом они работали в основном на датском рынке, где активные позиции занимает Ciklum. По словам Наталии основной секрет их успеха был в позиционировании и бесплатном обучении клиентов управлению проектами: они давали своего ПМа, учили клиентов Agile и активно его популяризировали на датских конференциях.

За счет этого они заработали себе имя. Правда на это ушло минимум 2 года :)

Чем все закончилось? Конечно же happy end-ом: Ciklum купила Kuadriga и полностью ее поглотила, а Наталья, поделив прибыль со своим датским партнером (по ее словам компанию изначально создавали для продажи), поехала в Мадрид получать MBA. Сейчас же она вернулась и стартует новый проект, в котором мы искреннее желаем ей успехов ;)

Еще одним приятным сюрпризом от ИТ отрасли Одессы стало не только наличие классных ко-воркингов, но и консультации молодых предпринимателей от стартап-акселератора WannaBiz.

b2ap3_thumbnail_IMAG0623.jpg

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

 b2ap3_thumbnail_IMAG0629.jpg   b2ap3_thumbnail_IMAG0624.jpg

Если вы прониклись темами докладов, то мы с радостью делимся с вами видео с конференции.

Надеемся, оно будет для вас полезным ;)

Привязка к тегам Conference IT sales
Просмотры: 5478
0
закрыть
Здравствуй, милый человек!

Надеюсь тебе понравится на нашем сайте! У нас много интересной информации и очень отзывчивое комьюнити. Добро пожаловать :)

Контакты

E-mail: info @ e-5.com.ua
Адрес: Киев, ул. Московская, 27
Тел.: +380677906611

Ищите нас в

Подписаться на новости