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


Источник

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

Вроде бы когда-то это был настроенный конвейер, но теперь его куски — как будто в разных зданиях. Особо не заботятся о том, что было «до» и что будет «после». А если всё падает, то люди поднимают руки: «Я не виноват. Я не знаю, как поднять».

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

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

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

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

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

В таких условиях у разработчика есть два пути: продолжать терпеть или брать инициативу в свои руки.

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

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

Команда, в которую я пришла как QA-инженер, была уже сформирована: стандартные процессы построены, атмосфера в коллективе — дружелюбная и спокойная. Через год моей работы встал вопрос о том, кто заменит скрам-мастера, который перешел в другую команду. Мне захотелось попробовать. Опыта в управлении и построении процессов не было, но почва для старта доброжелательная. Почему бы и нет?

Когда я встречаю очередную историю о том, как «инновационные» стартапы сливают миллионы на создание сервиса, а потом их сайт выглядит как нечто невразумительное, я искренне негодую. А прочитав статью о многозадачности и симбиозе от сооснователя и операционного директора «Тномера», выпал в осадок. €3 млн усвоены, а на сайт, видимо, не хватило.

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


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

Меня зовут Александр и я работаю бывшим разработчиком под Windows Phone в 2ГИС. Однажды я подошел к Кириллу, руководителю сервиса мобильных приложений, и спросил: «Скажи мне, Кирилл, руководитель сервиса мобильных приложений, что нужно сделать, чтобы от лица компании 2ГИС своим коллегам корпоративный мерч подарить?» Кирилл ответил, что 2ГИС — бирюзовая компания, а значит нужно проявить инициативу. Под катом — продуктовая история, корпоративные футболки, дух стартапа, проявление инициативы, много картинок и ни одного микросервиса.

Уже которую неделю один многоуважаемый ИТ-ресурс не отпускают бурления по поводу найма в ИТ. Хотя нет, правильно — «уже который год». Среди участников этих крайне бурных обсуждений есть два устойчивых лагеря, которые всё никак не найдут взаимопонимания.

Честно скажу — не знаю, как в других отраслях складывается ситуация, хотя, по слухам, много где есть нарекания. Но вот почему специалисты в ИТ, умные люди, всё никак не могут договориться?

Всем привет!

Меня зовут Женя Заремба. Пару месяцев назад я написал статью о продвижении видео на YouTube. Тогда я получил множество вопросов и в результате решил написать расширенный гайд по аналитике видео.

В этом материале мы поговорим о YouTube Analytics, преимуществах интеграции с Google Analytics, а также о дополнительных данных, которые можно получить, правильно настроив Google Tag Manager.

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

Автор — из старой школы. По разным причинам. Мне нравится заниматься «всем», помогать себе и компании, и я рассчитываю на отдачу — не только, и не столько, на финансовую. Я постоянно учусь. Но не только своей «основной», узкой специальности (=программирование), за которую платят, и ниже объясню, почему…

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

Дальше я постараюсь обобщить личный и известный мне опыт по этой проблеме.