Performance Review — это процесс, который компании выставляют как справедливый способ для карьерного роста и распределения благ между сотрудниками. На деле, этот процесс далёк от справедливости и невыгоден сотрудникам по следующим причинам:
Система закрыта для сотрудников.Читать полностью »
От нас, разработчиков, постоянно требуют дать оценку той или иной задаче. Зачем управленцам оценки, они вам сами расскажут. Зачем клиентам оценки — вам расскажут управленцы. Но нужны ли оценки самим разработчикам?
(c)
Практически с появления технологической отрасли в ней велась охота за «Белым китом» — метриками труда разработчиков. Возможно, само желание посчитать KPI программистов родилось из фразы, распространенной в традиционном бизнесе: «Вы не можете планировать, если не можете измерить».
Вслед за сотнями различных KPI, которыми пытались обвесить программистов, появилось множество различных методов анализа рабочих данных — от отслеживания направления взгляда на монитор до Scrum и Kanban. Измерения качества труда настолько хорошо работали во многих отраслях, что казалось вполне логичным перенести данный опыт на разработку программного обеспечения. Результат оказался обескураживающим.
Измерения и управление продуктивностью разработчиков не привели к появлению единого международного стандарта качества. Высокотехнологичные IT-компании разрабатывают собственные метрики… отдельные из них практически невозможно сравнить с традиционными KPI в других сферах деятельности.
В этой статье расскажем о самых интересных действующих метриках и о «метриках» в IT.
Читать полностью »
Долгое время работая в разных сферах ИТ, мы с исследовательской командой наблюдали все возможные проблемы становления разработчиков и все причины-следствия их дефицита. Нас интересовало: почему программист развивается в senior-специалиста так долго или вовсе им не становится? Откуда неоправданные ожидания с обеих сторон? И главное — что делать разработчику на каждом уровне, чтобы войти в привилегированную касту senior-ов, архитекторов, тимлидов и руководителей?
Мы провели обширное исследование среди программистов и их руководителей. Собрали требования к senior-разработчикам топовых компаний, возможности и пути к развитию до этого уровня, сгенерировали всевозможные инсайты и лайфхаки и трансформировали их в данную статью. Об всем этом и пойдет дальше речь.
Анализ описания вакансий на hh и требований, которыми поделились руководители в очных беседах, показал — единого подхода к определению уровня senior нет. В одной компании это тот, кто способен сам спроектировать сложный модуль, в другой — подключиться к доработке отдельных решений, в третьей — тот, кто просто круче остальных. Читать полностью »
Мировые тенденции свидетельствуют о том, что технология блокчейн привлекает не только отдельные компании, но и целые отрасли бизнеса. Разработчикам блокчейн-сервиса Wirex на глаза попался отчет консалтинговой компании McKinsey, посвященный возможностям и проблемам использования блокчейн в сфере страхования. Для нас этот отчет актуален вдвойне по причине скорого запуска нашего нового решения — децентрализованной страховой платформы Inchain, функционирующей на основании умных контрактов Ethereum. Inchain дает возможность пользователям застраховать свои криптоактивы, которые лежат на счету, например, какой-нибудь биржи. При этом страховой фонд находится под контролем держателей токенов Inchain.
Стабильность платформе обеспечивает ДАО-подобное управление страховым фондом, когда держатели токенов Inchain голосуют за решения и могут делать свои предложения. Все знают неудачный опыт The DAO, который привел к хардфорку Ethereum. В Inchain мы намерены учесть этот опыт и реализовать механизм ДАО так, чтобы с одной стороны предоставить участникам инструмент эффективного голосования, а с другой — исключить возможность вывода средств из Inchain ДАО. Подробнее о технологии вы можете узнать из нашего Whitepaper и в Pre-annonce посте на bitcointalk.org.
Далее на основе отчета консалтинговой компании McKinsey предлагаем разобраться в перспективах блокчейн-технологии в отрасли страхования.
Читать полностью »
Несколько лет назад Тренер Luxoft Agile Practice — Вячеслав Москаленко столкнулся с проблемой, что многие Скрам-команды не оценивают все истории в Бэклоге Продукта. А зря, ведь оценка дает нам прозрачную картину реального прогресса и возможность управлять ожиданиями наших заказчиков, не дожидаясь финишной прямой нашего проекта, когда уже поздно что-то менять.
«Вот так и родилась у меня мысль создать игру, через которую я смог бы заинтересовать команду начать оценивать все истории в относительных попугаях. И тогда мне пришла идея с закрашиванием пустых фигурок на флип-чарт бумаге.
Когда я в первый раз провел игру-раскраску на одном из мастер-классов местной ПМ-тусовки, даже не ожидал, что достаточно консервативные менеджеры проведут так весело время и получат объяснение „Что такое относительный стори поинт? В чем его ценность?“. С тех пор я провел эту игру на многих тренингах и нескольких конференциях, включая SECR-2015 и Agile Days Russia 2016».
Читать полностью »
Каждый из программистов и руководителей разработки хоть раз, но попадал на сроки, т.е. нарушал их, сильно или не очень.
Попробуйте открутить назад все Ваши проекты и оцените реальное опоздание по ним.
Может оказаться, что задержки достигают просто гигантских значений.
Автор статьи видел проекты с задержкой сроков в 400% и 700%!
Бытует мнение, что разрабатывать программы без опоздания невозможно в принципе.
Вообще, причина такой точки зрения ясна, ведь люди не провидцы и не могут видеть будущее.
На момент оценки трудоемкости ТЗ есть не всегда. И даже если оно есть, фактор неизвестности всё равно продолжает играть огромную роль – ведь люди, к сожалению, действительно не провидцы, и каким бы подробным не было ТЗ, всё равно остаются моменты, скрытые от глаз.
Кроме скрытой функциональности, на ошибочную оценку также довольно сильно влияет квалификация и личный опыт программирования самого оценщика (человеку без личного опыта программирования труднее оценить сколько времени займёт разработка).
Интересно, что сценарии (варианты) использования позволяют довольно точно оценить трудоемкость работ.
Практика показала, что можно достигнуть 20% точности (=%ошибки) при оценке. А ведь опоздание 20% это совсем не 700%, верно?
Как это сделать? Читать полностью »
Кадр из сериала Californication
Amazon для авторов электронных книг, которые публикуют свои тексты через Kindle Store, намерена в рамках эксперимента изменить систему выплаты за произведение. Теперь заработок автора будет буквально зависеть от того, сколько страниц в его книге прочитает её покупатель. В зависимости от этого и будет рассчитываться авторское вознаграждение. Как говорят в самой Amazon, компания пошла навстречу самим писателям, которые просили "… согласовать гонорар за книгу с её объёмом".
Читать полностью »
В комментариях к серии моих публикаций про светодиодные лампы не раз звучал вопрос о том, как померять коэффициент пульсаций без применения хитрых приборов вроде осциллографа или чего-то еще более специального. В связи с этим я предлагаю простую схему для примерной оценки коэффициента пульсаций при участии компьютера. Схема изначально разрабатывалась с учетом требований предельной простоты и дешевизны, и потому не отличается особо хорошими характеристиками; тем не менее, грубо оценить коэффициент пульсаций она поможет.
Читать полностью »
