Ты – программист. Я – эффективный менеджер. Ну, ты так считаешь. Может, даже статью про меня напишешь, наберешь кучу плюсов – тема-то благодатная. В статье обязательно слово «эффективный» в кавычки поставишь.
Я уже не работаю в вашей компании. Решил рассказать тебе, как всё было на самом деле. Скоро эта история тебе аукнется, что меня очень расстраивает, но будет лучше, если ты обо всём узнаешь от меня.Читать полностью »
Ты – эффективный менеджер. Я – программист. Ты умудрился стать моим начальником. Я занимаюсь автоматизацией нашего сраного завода. Ты делаешь вид, что руководишь этим процессом.
Я был на твоем собеседовании. Не на основном, а на кроссе. Я слышал, как ты рассказывал, что сам когда-то был программистом. Потом какими-то проектами внедрения руководил. Был очень успешным. Но за каким-то хером пришел в нашу дыру.
Ты утверждаешь, что знаешь об автоматизации все. Ты называешь себя властителем душ программистов. Говоришь, что они у тебя танцуют, как кобра под дудочку.
Что ж. Проверим.Читать полностью »
Прежде чем взяться за работу над user story, очень важно определить для себя критерии приемки. Это можно сделать, когда вы детализируете бэклог или планируете ближайший спринт. Некоторые команды для этого проводят специальные встречи, которые называются 3 Амиго (подробнее о них в прошлой статье), митинги, kick-off по спецификации или встречи-исследования.
Как не назови, большинству команд это дается с трудом. Главная сложность в том, что такие встречи неструктурированы, а их результат непонятен. Они отнимают много времени и попросту скучные. В итоге, сессии становятся нерегулярными или от них совсем отказываются.
Но есть простой способ сделать такие встречи короткими и очень продуктивными. И называется этот способ Example Mapping или составление карт тест-кейсов.
Алгоритмическая секция с написанием кода на доске или бумаге — один из важнейших этапов собеседования разработчиков для получения работы в Яндексе. Мы решили подробнее рассказать о том, как устроены эти секции, чтобы помочь будущим кандидатам в подготовке. Кроме того, надеюсь, многие из тех, кто не решается прийти в Яндекс на собеседование, опасаясь слишком сложных испытаний, после этого рассказа поймут, что в действительности всё не так уж и страшно!
Так что мы подготовили для вас следующие материалы:
В первой части доклада мы в общих чертах рассказали, как измеряем качество документации и эффективность ее разработки. Теперь погрузимся в детали подсчета метрик.
Рассказывает Юрий Никулин, руководитель службы разработки технической документации.
Для начала давайте определим, что такое производительность. В классическом понимании, это время на производство единицы продукции или количество продукции, произведенное в единицу времени.
Например, это количество произведенных телефонов за месяц или количество времени на производство тысячи телефонов. Возникает вопрос, как измерять интеллектуальный труд, которым занимается наш отдел.
Традиционный способ измерения задач в нашей отрасли – часы. Давайте посчитаем, сколько метрик в часах мы используем.
Первые, самые главные часы – те, что мы выставляем клиенту. В зависимости от ситуации, мы либо договариваемся о часах заранее, либо выставляем по факту – сколько затратил программист.
Вторые часы – те, что назвал программист, отвечая на вопрос «сколько тебе надо времени на решение задачи?». Если мы договариваемся с клиентом заранее, то именно эти часы и выставляем для продажи. Если оплата идет по факту, то мы спрашиваем оценку у программиста для целей планирования.
Третьи часы – сколько программист потратил на решение задачи по факту. С той плановой цифрой, которую он сам назвал, эти часы совпадают крайне редко, и это нормально – никто не умеет точно планировать свое время, потому что на работу программиста действует множество сил из окружающей среды – он отвлекается, он не в настроении, он сталкивается с непредвиденными трудностями и т.д.
Бывают и четвертые часы – когда мы выставляем клиенту сумму, отличную от заранее обговоренной. Разумеется, если условия нашего сотрудничества позволяют так поступать.
А теперь внимание, вопрос: где тут можно поработать над эффективностью? Или по-другому: эффективность чего мы будем повышать?Читать полностью »
Интегратор «никогда не доставлял функциональный сайт или мобильное приложение».
Гигант по прокату автомобилей Hertz судится за адский редизайн сайта.
Американская корпорация наняла фирму «монстра» по IT управлению Accenture в августе 2016 года, чтобы полностью обновить свое присутствие в Интернете. Новый сайт должен был заработать в декабре 2017 года. Но неготовность привела к срыву сроков до января 2018 года, а затем ко второму сдвигу до апреля 2018 года, которая, как нам сказали, были сорваны.
Читать полностью »
Гибкая методологи разработки — отличная идея, которую слишком усложнили. Agile Lite — попытка упростить ситуацию. Вам не нужны книги или семинары, чтобы объяснить Agile Lite. Нужен только небольшой текст с несколькими пунктами. Вот этот текст.
Agile Lite довольно прост. Его можно применить к любому проекту при условии, что работа разбивается на более мелкие задачи (issue). Как и другие гибкие методологии, он использует короткие циклы разработки — спринты. Но в отличие от них, Agile Lite явно признает распространённость выгорания в индустрии разработки программного обеспечения и пытается смягчить его напрямую путём внедрения цикла «три недели разработки/одна неделя отдыха.
Читать полностью »
Не знаю почему, но вам понравилась история про одного парня. Если помните, он ушел.
Куда ушел, чем занимается, каковы успехи – не скажу, ибо не имею от него на то разрешения. Но его история получила неожиданное продолжение.
Я, как вы поняли, с ним знаком. И не просто знаком – мы вместе учились на приборостроительном факультете. На носу День Радио, и он прилетел обратно в нашу дыру на встречу выпускников. Позвал меня выпить пива, и рассказал мне одну историю. Про одну девушку.Читать полностью »
Это вторая часть из цикла четырех статей о разработке физических продуктов. Если вы пропустили Часть 1: Формирование идеи, обязательно её прочтите. Вскоре вы сможете перейти к Части 3: Конструирование и Части 4: Валидация. Автор: Ben Einstein. Оригинал Перевод выполнен командами фаблаба FABINKA и проекта РУКИ.
Часть 2: Дизайн
Каждый шаг на стадии дизайна – изучение клиента, каркасное моделирование (wireframing, подробнее по-русски), визуальный прототип – нужен для проверки гипотез, как будет выглядеть продукт и как пользователи будут взаимодействовать с ним.
Рисунок 2.1 Этапы дизайна продуктов
Читать полностью »
