Рубрика «оценка»

Культура разработки: как оценивают производительность и эффективность - 1
(c)

Практически с появления технологической отрасли в ней велась охота за «Белым китом» — метриками труда разработчиков. Возможно, само желание посчитать KPI программистов родилось из фразы, распространенной в традиционном бизнесе: «Вы не можете планировать, если не можете измерить».

Вслед за сотнями различных KPI, которыми пытались обвесить программистов, появилось множество различных методов анализа рабочих данных — от отслеживания направления взгляда на монитор до Scrum и Kanban. Измерения качества труда настолько хорошо работали во многих отраслях, что казалось вполне логичным перенести данный опыт на разработку программного обеспечения. Результат оказался обескураживающим.

Измерения и управление продуктивностью разработчиков не привели к появлению единого международного стандарта качества. Высокотехнологичные IT-компании разрабатывают собственные метрики… отдельные из них практически невозможно сравнить с традиционными KPI в других сферах деятельности.

В этой статье расскажем о самых интересных действующих метриках и о «метриках» в IT.
Читать полностью »

Долгое время работая в разных сферах ИТ, мы с исследовательской командой наблюдали все возможные проблемы становления разработчиков и все причины-следствия их дефицита. Нас интересовало: почему программист развивается в senior-специалиста так долго или вовсе им не становится? Откуда неоправданные ожидания с обеих сторон? И главное — что делать разработчику на каждом уровне, чтобы войти в привилегированную касту senior-ов, архитекторов, тимлидов и руководителей?

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

Senior, who the f… is Alice Senior?

Анализ описания вакансий на hh и требований, которыми поделились руководители в очных беседах, показал — единого подхода к определению уровня senior нет. В одной компании это тот, кто способен сам спроектировать сложный модуль, в другой — подключиться к доработке отдельных решений, в третьей — тот, кто просто круче остальных. Читать полностью »

image Мировые тенденции свидетельствуют о том, что технология блокчейн привлекает не только отдельные компании, но и целые отрасли бизнеса. Разработчикам блокчейн-сервиса Wirex на глаза попался отчет консалтинговой компании McKinsey, посвященный возможностям и проблемам использования блокчейн в сфере страхования. Для нас этот отчет актуален вдвойне по причине скорого запуска нашего нового решения — децентрализованной страховой платформы Inchain, функционирующей на основании умных контрактов Ethereum. Inchain дает возможность пользователям застраховать свои криптоактивы, которые лежат на счету, например, какой-нибудь биржи. При этом страховой фонд находится под контролем держателей токенов Inchain.

Стабильность платформе обеспечивает ДАО-подобное управление страховым фондом, когда держатели токенов Inchain голосуют за решения и могут делать свои предложения. Все знают неудачный опыт The DAO, который привел к хардфорку Ethereum. В Inchain мы намерены учесть этот опыт и реализовать механизм ДАО так, чтобы с одной стороны предоставить участникам инструмент эффективного голосования, а с другой — исключить возможность вывода средств из Inchain ДАО. Подробнее о технологии вы можете узнать из нашего Whitepaper и в Pre-annonce посте на bitcointalk.org.

Далее на основе отчета консалтинговой компании McKinsey предлагаем разобраться в перспективах блокчейн-технологии в отрасли страхования.
Читать полностью »

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

Как планировать и оценивать проекты в Agile? - 1 «Вот так и родилась у меня мысль создать игру, через которую я смог бы заинтересовать команду начать оценивать все истории в относительных попугаях. И тогда мне пришла идея с закрашиванием пустых фигурок на флип-чарт бумаге.

Когда я в первый раз провел игру-раскраску на одном из мастер-классов местной ПМ-тусовки, даже не ожидал, что достаточно консервативные менеджеры проведут так весело время и получат объяснение „Что такое относительный стори поинт? В чем его ценность?“. С тех пор я провел эту игру на многих тренингах и нескольких конференциях, включая SECR-2015 и Agile Days Russia 2016».
Читать полностью »

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

Попробуйте открутить назад все Ваши проекты и оцените реальное опоздание по ним.

Может оказаться, что задержки достигают просто гигантских значений.

Автор статьи видел проекты с задержкой сроков в 400% и 700%!

Бытует мнение, что разрабатывать программы без опоздания невозможно в принципе.

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

На момент оценки трудоемкости ТЗ есть не всегда. И даже если оно есть, фактор неизвестности всё равно продолжает играть огромную роль – ведь люди, к сожалению, действительно не провидцы, и каким бы подробным не было ТЗ, всё равно остаются моменты, скрытые от глаз.

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

Интересно, что сценарии (варианты) использования позволяют довольно точно оценить трудоемкость работ.

Практика показала, что можно достигнуть 20% точности (=%ошибки) при оценке. А ведь опоздание 20% это совсем не 700%, верно?

Как это сделать? Читать полностью »

image
Кадр из сериала Californication

Amazon для авторов электронных книг, которые публикуют свои тексты через Kindle Store, намерена в рамках эксперимента изменить систему выплаты за произведение. Теперь заработок автора будет буквально зависеть от того, сколько страниц в его книге прочитает её покупатель. В зависимости от этого и будет рассчитываться авторское вознаграждение. Как говорят в самой Amazon, компания пошла навстречу самим писателям, которые просили "… согласовать гонорар за книгу с её объёмом".
Читать полностью »

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

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

Оказывается, человек – все еще биологическое существо, и как бы мы все с вами не мечтали – создать из него программируемую машину покупок пока не удается. Да, существуют тысячи людей, что ежедневно молятся лишь о том, чтобы завтра все мы с вами встали бы утром, и завидев крупный заголовок Н1, яркую оранжевую кнопку call-to-action с правильными скруглениями – начали бы безудержно покупать все, что попало. Но увы, пока этого не происходит, человеческое подсознание гораздо сильнее программируемых маркетинговых приемов и каждый раз совершенно особым образом реагирует на увиденное на сайте, генерируя совершенно особые эмоции. Именно воздействие на эмоции, ощущения, особенности людского восприятия оказывается на практике в тысячу раз важнее, чем механическое следование «Ководству», эвристикам Нильсена или копированию успешного проекта. Читать полностью »

Введение

Статью меня сподвигла написать эта: habrahabr.ru/post/233895

Прямое обращение: админы хабры, пожалуйста не ломайте нам кайфомашину закручиванием гаек! Дайте потрясти. А теперь тезисы:
— оценка материалов всместо оценки личности
— проблема с участием в активной жизни сообщества
— боязнь и нежелание писать статьи
— fun factor
— карма и совок в головах, неправильная уравниловка
— убей в себе государство

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

Читать полностью »

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

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js