Pull to refresh
1
0
Send message

Как IT-специалисту развивать софт-скиллы, и зачем это вообще нужно

Reading time8 min
Views17K

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

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

Как обычно, истина где-то посередине. Меня зовут Дмитрий Петренко, я из Московского кредитного банка, и именно на примере МКБ я хочу немного рассказать про развитие айтишных софт-скиллов. Мы занимаем второе место в списке банков с частным капиталом, у нас более 5 000 сотрудников, 700+ штатных IT-специалистов и множество IT-аутсорса. Так что компетенции в плане общения и совместного выполнения задач в нашем случае — штука важная.

Читать далее
Total votes 19: ↑15 and ↓4+20
Comments38

Перевод книги «Социальная архитектура»: Глава 5. Дизайн, разработка, инновации

Reading time16 min
Views4.8K
«Размер и разнообразие сообщества является ключевым фактором.»

imageДавайте рассмотрим инновации, которые Википедия определяет как «развитие новых ценностей посредством решений, которые отвечают новым требованиям, не явным потребностям или потребностям старых клиентов или рынков в новых способах добавления стоимости». На самом деле это значит решать проблемы более дешевым способом. Звучит просто, но истории рухнувших технологических гигантов говорят об обратном. Я постараюсь объяснить, почему команды часто понимают это не правильно, и предложу способ, как нужно создавать что-то инновационное.
Читать дальше →
Total votes 16: ↑16 and ↓0+16
Comments0

Проблемы продуктовых команд и инструменты спасения

Reading time5 min
Views2.3K

Всем привет! Как Product Owner клиентского мобильного приложения Первой грузовой компании (ПГК), я уже рассказывала про формирование продуктовой команды и развитие компетенций ее участников. В этот раз поделюсь тем, как выявлять «боли» внутри команды и решать их.

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

Читать далее
Total votes 4: ↑2 and ↓20
Comments5

«Я не ответственный, я — Responsible» — как объяснить бабушке, что такое RACI-матрица

Reading time7 min
Views52K


Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала я Саше и Маше про ToDoList и таск-трекеры и нарисовала им на холодильнике импровизированную асану. Маша наклеила стикеры с задачами и сроками, Саша терпеливо кивнул. Настолки состоялись.

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

Но потом решила, что всё нормально, лезут, т.к. вспомнила, что видела RACI-матрицу для распределения ответственности с шуточным объяснением через поездку семьи на дачу. Полезла искать эту картинку для Саши с Машей, нашла, а в ней куча ошибок:



Простите. Не могу промолчать. Не надо так.
Читать дальше →
Total votes 69: ↑63 and ↓6+74
Comments45

Переводы всех статей Пола Грэма на всех языках (210+)

Reading time7 min
Views32K
image
(иллюстрация Asya_Dyu)

Пол Грэм — один из самых уважаемых людей среди ИТишников, основателей и инвесторов. Он первоклассный программист (написал два языка программирования), хакер, создатель дерзкого акселератора Y Combinator, философ.

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

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

Сейчас около 2 миллиардов человек могут прочитать эссе Пола Грэма. Моя задумка в том, что если перевести его эссе на топ-20 языков, то это даст возможность еще 2 миллиардам людей случайно наткнуться на перевод на родном языке (как это было у меня) и встать на путь стартапера.

Читать лучше в оригинале, но путь к оригиналу иногда бывает (только) через перевод.
Читать дальше →
Total votes 28: ↑21 and ↓7+18
Comments15

Как вести проект без релизов

Reading time6 min
Views4.9K

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

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

Читать далее
Total votes 7: ↑5 and ↓2+5
Comments10

Классические ошибки управления проектами при запуске стартапов

Reading time13 min
Views9.2K

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

В статье собраны типовые ошибки с описанием последствий, которые встречаются, если для сотрудника образа мышления project manager поставить задачу в части создания / корректировки нового продукта (бизнеса в миниатюре), что больше подходит для product manager.

Читать далее
Total votes 5: ↑4 and ↓1+4
Comments0

5 моделей эффективного командного взаимодействия

Reading time6 min
Views78K
Выбор моделей и подходов для повышения эффективности работы команды — это извечная головная боль менеджеров продуктов, тим лидов, собственников бизнеса, HR, ученых и психологов.

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

image
Читать дальше →
Total votes 11: ↑10 and ↓1+9
Comments2

Разбиение пользовательских историй – метод гамбургера

Reading time5 min
Views25K
Предлагаю вашему вниманию перевод небольшой статьи Гойко Аджича на тему разделения пользовательских историй от 2012 года, с иллюстрациями и примерами автора: "Splitting User Stories: The Hamburger Method" — сделал его, в первую очередь, для себя.

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

Решение: Метод гамбургера

image
Читать дальше →
Total votes 10: ↑9 and ↓1+8
Comments1

Disciplined Agile. В чем смысл?

Reading time5 min
Views4.2K

Но есть же Scrum?!

Не поймите меня неправильно. Я обожаю Scrum. Я уже много лет использую Scrum везде, где он действительно работает. Но давайте посмотрим правде в глаза – фраза из Scrum Guide “Scrum is easy to understand, hard to master” [1] – очень точно отражает суть [Примечание: по-русски “легок для понимания, сложен для освоения”. Почему-то в официальном русском переводе цинично ограничили максимой “Scrum - прост”]. И это объясняет, почему так много команд легко впадает в ересь “Зомби-Скрама”.

Из-за этой сложности для понимания, командам обязательно нужен хороший тренер, обладающий здоровым эмпирическим подходом и способный помочь запустить процесс, по-настоящему основанный на практическом опыте. Механическое исполнение предписанных ритуалов не способно дать жизнеспособного процесса. Но много ли таких тренеров? Это легко узнать просто взяв просто цифры с сайта scrum.org [2]. Более чем 300 000 сертифицировано как PSM I. Если русскоязычный цикл статей зайдет аудитории Habr, я обязательно расскажу о том, что на деле значат все эти сертификации, но давайте пока просто примем, что любой человек способный прочитать и понять слова в Scrum Guide, легко сдаст PSM I. Теперь посмотрим на сертификации, которые требуют понимания и практического опыта. Для сдачи PSM II уже надо продемонстрировать умение применять Scrum на практике, и сдали его уже всего лишь чуть больше 8 000 человек. И всего лишь чуть больше 800 сдали экзамен, который действительно подтверждает глубокое понимание Scrum - PSM III. Не больше 10 000 человек на миллионы команд по всему миру.

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

Читать далее
Total votes 3: ↑2 and ↓1+3
Comments7

Почему DevOps и Agile не работают в России, часть первая, Enterprise

Reading time5 min
Views35K

Пару лет назад, человек из Wrike написал серию статей про красную корпоративную культуру, причём во второй части буквально в 3 абзацах был весь смысл 4 статей. Было написано очень завуалировано и мягко, я же сегодня распишу, по сути, этот абзац в целую статью на примере крупных игроков российского рынка, в которых я поработал, сравню с малым бизнесом, в котором я работал ранее, а также с гос. структурами (спойлер, отличии с последними – минимальное).  

Я не буду таким добрым как автор там, и напишу про многие вещи прямо.

Читать далее
Total votes 59: ↑37 and ↓22+24
Comments100

Техподдержка в эпоху DevOps

Reading time10 min
Views19K



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


В такой ситуации успешное внедрение DevOps-практик может оказаться практически невозможным.


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

Читать дальше →
Total votes 21: ↑18 and ↓3+15
Comments19

Scrum для аналитиков. Как мы построили процессы в Кошельке

Reading time15 min
Views6.8K

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

Так-так-так
Total votes 6: ↑5 and ↓1+4
Comments6

Scrum vs Kanban: в чем разница и что выбрать?

Reading time7 min
Views308K
Когда существуют варианты – важно не ошибиться и изучить все детали и возможности, чтобы остановиться на лучшем. Выбирать между методами управления разработкой не всегда просто, особенно если это Scrum и Kanban.

image
Читать дальше →
Total votes 27: ↑26 and ↓1+25
Comments18

Поиск задач в JIRA (простым языком). Часть 2: Продвинутый поиск

Reading time16 min
Views203K
Структуру JQL-запросов без примеров сложно понять специалистам, не знакомым ранее с JIRA.

Мы уже успели рассказать про быстрый и базовый поиск. Теперь же прейдем к самому мощному из трех методов — к продвинутому поиску.

В этом режиме вы можете указывать критерии, которые нельзя задавать в остальных предыдущих двух режимах (например, сортировку ORDER BY). Но придётся освоить создание структурированных запросов с помощью JIRA Query Language (JQL).


Читать дальше →
Total votes 20: ↑18 and ↓2+16
Comments32

ТОП-4 зависимости между KPI входящей линии контакт-центра, которые должен знать каждый руководитель

Reading time6 min
Views7.7K

Отраслевой стандарт COPC СХ release 6.1 по состоянию на январь 2020 года включает описание 60 KPI контакт-центра. На деле индикаторов больше: порядка 200, причем 150+ из них реально использовать на всех уровнях операционного управления: от супервизорского до директорского. 

Проблема только в том, что KPI сильно взаимосвязаны. Мы провели небольшой эксперимент. Взяли брошюру авторитетной американской компании MetricNet “Contact Center KPIs Definitions & Correlations”, в которой описаны взаимосвязи между основными показателями обычной входящей линии, и изобразили их в виде графа: 

Читать далее
Total votes 4: ↑2 and ↓2+2
Comments4

Продакт и приоритизация: как оценить задачи проекта?

Reading time5 min
Views4.2K
Иногда в команде появляются разногласия по продукту: какие сейчас задачи в приоритете. Чтобы между разработчиками и менеджерами не встала стена непонимания, продакт должен провести приоритизацию. А как сделать это правильно — читайте в статье.

Опытные продакты знают, что просто пальцем в небо не ткнёшь и среди всех горящих задач нужно выделить самые весомые. Миша Карпов, ex-Product Director Skyeng, через одно из исследований выяснил, что российские и зарубежные компании разбивают приоритизацию на два этапа: быстрая и медленная оценка.

image

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

Читать дальше →
Total votes 3: ↑2 and ↓1+2
Comments0

Как справиться с декомпозицией задач и не перестараться

Reading time10 min
Views46K
Всем привет!

Меня зовут Виктор, я системный аналитик в компании «Спортмастер». И сегодня я хотел бы поговорить о декомпозиции задач и передачи их в разработку. Любой объект состоит из частей, будь это автомобиль или программный продукт. И чтобы собрать любой из этих объектов в единое целое из составных частей, потребуется время. Иногда — даже очень много времени. Особенно, если перед этим вы не просто разобрали основную часть, а решили докопаться до сути на атомарном уровне.


Где же та грань между адекватной постановкой задач и тотального хаоса? Поделюсь примером того, как к нам в «Спортмастере» периодически поступают задачи в разработку от бизнеса.
Читать дальше →
Total votes 15: ↑15 and ↓0+15
Comments10

Проводим ретроспективы для распределенных команд (и как Trello в этом помогает)

Reading time7 min
Views13K

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

Инструменты

Я пользовался большим количеством инструментов, из которых можно выделить основные: Miro - как интерактивный флипчарт, с которым может взаимодействовать вся командa; Google Docs с секциями помапанными на стадии ретроспектив; Confluence (так как все мои проекты пронзены Atlassian-стеком); а также, порой, Jira (вау, это была достаточно плохая идея)!

Я думаю что все пытались нащупать тот самый инструмент, который можно применить фактически в любой области!

И вот я бы выделил основными критериями для проведения Ретро и собирания фидбека о Демо в подобных инструментах:

1. Насколько хорошо оно работает на уровне объектов (во время обсуждений). -> в идеале тут хотелось бы видеть карточки (все таки мы в физическом мире работаем со стикерами)

2. Быстрая и эффективная работа с карточками / объектами

3. Подсветка / теги для карточек / объектив (чтоб все могли), не важно как (цвет, тег, еще какая-то штука позволяющая дифференцировать карточки)

4. Перетасовка / изменение порядка карточек / объектов / айтемов

5. Как можно меньшее время, затраченное на следующую последовательность действий: создание секции (списка) -> добавление в него объектов / карточек -> тегирование / подсветка айтемов (членами команды) -> добавление комментария к айтему.

Читать далее
Total votes 3: ↑2 and ↓1+5
Comments6

Как «продать» технические задачи бизнесу

Reading time12 min
Views4.8K

Поддерживать высокое техническое качество кода — прямая обязанность техлида. Но чтобы этого добиться, зачастую приходится доказывать начальству и заказчикам необходимость вкладывать в улучшение кода силы и время. Как сделать это, не стаптывая в бесконечных согласованиях железные башмаки и не стирая язык до мозолей? Об этом в своем докладе на конференции TechLead Conf 2020 Online рассказал консультант Better Life Company Алексей Дерюшкин.

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

Читать далее
Total votes 11: ↑10 and ↓1+13
Comments2

Information

Rating
Does not participate
Registered
Activity