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

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

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

Представьте, что Вы – руководитель службы поддержки, состоящей из 10 человек, и Ваша команда обслуживает коллектив из 200 команд, в каждой из которой по 7-10 человек. Это минимум 1400 человек, ежедневно засыпающих Вас работой.

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

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

И тут начинаются жалобы на медленную отработку запросов…

Естественно, в этой ситуации руководителю нужны фактические данные, а не слова.

На помощь приходит когортный анализ.

После того как Иван познакомился с когортным анализом, он терпеть не мог любые виды слащавых метрик.

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

Как-то руководитель попросил Ивана разобраться, почему в течение 3- недель непрерывно падает конверсия прохождения стенда командами:

Сайт The Daily WTF уже 14 лет собирает курьёзные, дикие и/или печальные истории из мира ИТ. Я перевёл несколько рассказов, показавшихся мне интересными. Все имена и названия компаний изменены.

На работу за 3 000 миль

Правдивая история из личного опыта нашего автора Snoofle. [Оригинал]

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

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

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

В данной статье я хочу рассказать, как можно со всем этим входящим хаосом работать.

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

Выяснение реальной проблемы

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

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

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

Эпиграф: Верблюд — это лошадь, сделанная по всем требованиям заказчика.

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

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

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

Каждое взаимодействие с внешним миром, по сути, не что иное, как набор пользовательских историй (они же User Story).

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

Или

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

Или почти бесконечность своих вариантов.

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

А дальше начинаются сценарии использования (они же Use Cases), крупные и мелкие, детализированные и нет:

1. Пользователь подсчитывает свои средства на поездку;
2. Пользователь определяется со способом поездки – через турагентство или своим ходом;
3. Пользователь осуществляет подбор наиболее дешевых вариантов покупки тура (или билетов/отеля/дома)
4. ...

Мир бизнеса стремительно «оцифровывается». Так что принципиально важно понимать, что такое digital-консалтинг и почему он нужен компаниям-клиентам, а агентства должны развиваться в этом направлении.

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

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

Как правильно оформить сотрудника? Сегодня работодатели привыкли выбирать между трудовым и гражданско-правовым договорами. Между тем, уже пару лет как появилась возможность взять на работу «дистанционного работника». Этот вариант имеет свои весомые преимущества: сотрудник не обязан постоянно сидеть в офисе, но остается на «коротком поводке» трудового договора. Давайте разберемся, подойдет ли такой вид сотрудничества именно вам, и поймем, как избежать возможных проблем.

Работать в режиме home office — мечта большинства копирайтеров. Воплощая ее, многие мои коллеги ушли во фриланс, а некоторые трудятся на себя официально. Я же — штатный, но дистанционный сотрудник московской компании, и считаю, что мне крупно повезло.



За восемь месяцев с момента трудоустройства в Mobile Dimension я приезжала в офис всего четыре раза: познакомиться и пройти обучение, на корпоратив, на большой контент-планнинг-митинг с командой, а в позапрошлые выходные вместе с ребятами участвовала в IT-марафоне RUNIT :). В остальное время с непосредственным руководством и коллегами по проекту общаемся часто, но в мессенджере или по телефону.

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

Привет, уважаемые хабровчане!

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

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

Внимание владельцам малых и средних IT-, интернет- и софтверных компаний! В цепкие руки Alconost попал еще один ценный доклад со столь же ценной IT-конференции ISDEF. В нем Александр Лысковский, сооснователь и CEO Alawar Entertainment, рассказал, как расти компании и что необходимо делать для ее успешного роста.

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

Интересный факт: любая деятельность, связанная со стратегией, кажется несвоевременной. Мол, если у компании все хорошо, то зачем тратить силы и время на непонятную стратегию? С другой стороны, при проблемах, в кризисное время, тоже не до стратегии – надо быстрей что-то делать, а не «планы планировать».

Управление продуктом становится важнейшей частью функционирования большинства компаний. Однако для некоторых стартапов и даже крупных команд процесс управления продуктом остается не до конца понятным явлением.

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

Привет!

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



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

Привет, друзья!

По результатам статьи «Как мне стать project manager’ом в IT, если до этого я работал(-а) на похожей позиции, но не в IT?» возникли вопросы, а что же делать Team Leads (TL), которые уже работают в IT? Как этим Team Leads стать руководителями проектов? В данной статье намеренно не будет упоминаться позиция Tech Lead, которая в моем понимании ничем не отличается от Team Lead, с точки зрения роста из нее в PM. Таким образом сокращение TL можно читать как Team Lead, так и как Tech Lead.

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

Если после прочтения данного вступления вы все еще считаете, что вам почему-то все равно необходимо вырасти из TL в Project Manager’а, и вы готовы вкладывать время и силы в свое развитие — welcome читать дальше. Если вы не готовы вкладывать в себя и учиться, практиковаться, учиться и снова практиковаться — дальше читать смысла нет. Не тратьте свое время.

Чтобы избежать некоторой путаницы, стоит упомянуть, что разбираю в этой статье только вариант «TL->PM». Опцию «Инженер->TL» не рассматриваю для сокращения объема статьи.

Привет, друзья!

Так получается, что со мной периодически связываются мои знакомые и знакомые моих знакомых, которым меня порекомендовали, с примерно одним и тем же вопросом: «Как мне стать project manager'ом в IT, если до этого я работал(-а) на похожей позиции, но не в IT?».

Так как подобных запросов накопилось несколько штук за довольно короткое время, я решил написать об этом отдельную статью. Ну вы понимаете — я же ленивый, и теперь смогу сразу давать ссылку на этот текст, вместо очередного повторения уже несколько раз сформулированных ответов. Статья не претендует на универсальность — это только мой взгляд на ситуацию. В то же время скажу, что когда проводишь собеседования, нанимаешь и обучаешь project manager'ов — накапливается довольно много общих критериев, отвечающих на вопрос «А что же на самом деле должен знать и уметь IT project manager?», чтобы успешно работать в IT.

Кстати, знание английского языка в статье даже не обсуждается. Оно просто обязательно.

Поехали?

С чем сейчас работает руководитель проекта? Какие инструменты использует, чтобы планировать, собирать данные, контролировать ситуацию, готовить отчеты?

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

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

• Asana
• Trello
• SmartSheet
• Мегаплан
• JIRA
• Clarizen

По результатам исследований, 92% маркетологов считают вебинары эффективным способом привлечения лидов. 62% всех В2В компаний проводят вебинары в качестве рекламы своего бренда. Но несмотря на такие высокие показатели, многие бренды все еще не знают как привлечь внимание своей аудитории к вебинару и каким, собственно, он должен быть.

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

Начинать подготовку к мероприятию (особенно в первый раз) лучше минимум за месяц. Со второго-третьего раза вы уложитесь в две недели, но с каждым новым спикером (моя компания организовывает вебинары внутри услуги «iБрендинг») мы закладываем на подготовку месяц. Это лучше, чем переносить вебинар из-за того, что мало слушателей. Речь, конечно, не о бесплатных мероприятиях, с ними все проще.

У нас проект по разработке и внедрению новой ИТ-системы! И нужен ПМ…
Случалось? Куда ж без этого. И вроде бы рынок насыщен всевозможного рода руководителями проектов.

— Выбирай! У всех прекрасный богатый опыт. Есть ПМ-ы с опытом внедрения проектов в Строительстве и Оборонке. Есть ПМ-ы с опытом внедрения медицинских проектов. Есть даже в Авиастроительстве! Что тебе еще надо!? Уровень ответственности и требовательности в этих отраслях – полный отвал башки.
— А он знает ИТ?
— Зачем тебе это?! У него прекрасные знания методологии ведения проектов…это – главное!