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



Написать идеальное ТЗ проще простого:

1. Договорился о минимальном этапе (на 2-4 недели).
2. Описал юзер-стори по шагам.
3. Составил список экранов будущей системы.
4. Прописал названия методов API и форматы данных.
5. Запросил тестовый контент и составил таблицы с тестовыми данными.
6. Сформулировал из всего этого цели и задачи.
7. Согласовал план работ и выставил задачи в таск-менеджер.

Но не тут-то было! Давайте я расскажу, как все происходит в реальной жизни, а также поделюсь своими лайфхаками, как я с этим справляюсь.

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

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

Сегодня я хочу поделиться двухлетним опытом проведения игры getKanban в Туту.ру. В целом, игровые механики мы используем довольно активно: играем в getKanban, Playing Lean, Lego Serious Game и т. д. Но getKanban, по нашему мнению, наиболее цельная и качественная игра. Для нас эта игра уже стала традицией и привычным инструментом обучения и коммуникации. Возможно, кто-то из читателей возьмет наш опыт на вооружение.

Большинство людей не умеют адекватно оценивать сроки выполнения задач. Ой как это заставляет порой понервничать… Тут и «дэдлайн подкрадывается незаметно». И перестраховка в 500% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.



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

Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)

Итак. Если вы не садист или моральный урод, а ваши сотрудники — не мазохисты, то сомневаюсь, что кому-то из вас наказания доставляют удовольствие. Мне — нет.

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

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

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

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

Честно говоря, написание этого текста преследовало вполне корыстные цели: он является некоторой лакмусовой бумажкой для отправки людям, с которыми предстоит сотрудничать.

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

Пару недель назад в Москве прошла AgileDays-2015 — самая крупная в РФ конференция по современным методам управления в разработке.

• Два дня, пять треков, огромные залы московского Центра Международной Торговли (не путать с WTC).
• Темы:
  • Agile-менеджмент — от высокоуровнего управления разработкой в неповоротливых компаниях-монстрах, до «бережливого старта» в стартапах.
  • Продуктовый аспект — как не только правильно разрабатывать, а творить именно нужное и правильное.
  • Специфические вопросы процессов и технологий — тестирование и бизнес-анализ, юзабилити и проектирование.
  • Современные архитектурные практики — *DD, и даже немного о функциональном программировании.

Вращаясь в «продвинутых» кругах часто кажется, что Agile-подходы уже «захватили весь мир», и хватит уже говорить о понятном и общеизвестном. Но в реальной жизни, все конечно гораздо запущенней — есть успешная когорта «early adopters», и как видно в широко известной картинке «дилеммы инноватора», далее идет большая пропасть, и либо те, кто совсем не в курсе, либо кому про Agile «все понятно, ибо сосед-Рабинович напел». Это видно даже по ряду недавних публикаций на мегамозге. Поэтому реальный, и даже не всегда успешный, опыт от тех, кто в теме и нашел и все грабли, и кучу ништяков — очень полезен, и гораздо более актуален, чем даже книги, как правило уже устаревающие к моменту публикации. Докладчики — не евангелисты, а практики, из крупных компаний и стартапов, хотя да, были и консультанты, рассказывающие о «сгибании несгибаемого» — типа аджайлизации банков.

Там было круто — вы многое пропустили, если вас там не было. Но. Видеозаписи и прочие материалы докладов публикуются и будут доступны всем. Запись моя, добротная, все как обычно — монтаж, несколько камер, экран, звук с микрофона, технологии оживления.

И я, как член программного комитета, заботящийся о том, чтобы докладчики донесли свои знания до всех заинтересованных, попробую сделать серию публикаций, включающих и видео доклада, аннотации и слайды, и мой очень краткий постобзор. Слона надо есть по частям — еще готово не все видео, смонтированное надо еще отсмотреть и отрефлексировать, да и большие статьи отпугивают своим объемом и читателей и писателей — стыдно признаться, что я, за несколько заходов, но так и не смог дописать за год эпический обзор 72 видеодокладов с прошлого AgileDays-2014, и даже обзор 2011 осилил только через полгода. Конечно же, обзор Agile-конференции надо делать итеративно, максимально быстро отгружая value потребителям. И, как принято в Agile, возможно даже прекратить поставки, если продукт не понравится пользователям…

Итак, смотрите и решайте — такой формат ОК или нет…

Прошлой осенью прошла менеджерская конференция LeanKanban Russia-2014.

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

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



Конференция чисто менеджерская, от поднимаемых тем и аргументов, и местами сильно избитого бизнес-жаргона, у «сферического линейного разработчика» наверняка будет butthur идиосинкразия («WAT?? Процессы? Инновации? Менеджеры-бездельники! Фигли думать, трясти надо!»), но с точки зрения менеджмента — это самые свежие тренды. Так что наверно, в отделенном от хабра мозге мегамозге, обзору будет самое место.

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

Ниже — вольный пересказ книги Running Lean, автор — Ash Maurya. Рейтинг Амазона — 4.8 из 5. Книга, насколько я знаю, на русский язык еще не переведена.

Здесь изложена суть книги в объеме меньшем 1% объема книги, по моей оценке. Все вопросы освещены так, как я их понял, что необязательно совпадает с тем, как их хотел донести автор.

Допускаю, что нарушаю чьи-то права: пересказ лицензии не требует, но иллюстрации взяты из книги. Автору я писал в попытке прояснить этот вопрос, но ответа не получил.

Блог автора кгиги: practicetrumpstheory.com.

Структура пересказа

• Введение в процесс Running Lean
  • Три важнейших методологии
  • Roadmap
• Описание процесса Running Lean
  
  • Составьте «План А»
    
    • Определите кто клиенты
    • Создайте бизнес-модели
    • Ранжируйте бизнес-модели
  • Протестируйте и измените план
    
    • Подготовьтесь к проведению экспериментов
    • Категории рисков и четыре фазы тестирования плана
      
      • Фаза 1. Поймите проблему
      • Фаза 2. Найдите решение
      • Фаза 3. Валидируйте качественно
      • Фаза 4. Верифицируйте количественно
• Три стадии стартапа
  
  • Соотношение трех стадий стартапа и четырех фаз тестирования плана
  • Держите правильный фокус
  • Привлекайте финансирование вовремя
  • Масштабируйте правильно

1. Мир пытается оставить тебя тупым. Начиная от банковских платежей и процентов и заканчивая чудо-диетами — из необразованных людей легче вытрясти деньги и ими проще управлять. Занимайтесь самообразованием столько, сколько можете — для того, чтобы быть богатым, независимым и счастливым.

Для лучшего понимания этого поста, прочитайте сначала предыдущий пост про прокрастинацию.

Если бы, когда я учился в школе, вы спросили меня прокрастинатор ли я, я бы конечно ответил “да”. Учеников школы учат “держать темп” с крупными проектами. И я гордо держал темп больше чем кто-либо кого я знаю. Я никогда не пропускал дедлайн, но делал все ночью перед сроком сдачи работы. Я был прокрастинатором.

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

Без всякого сомнения в моей голове была Обезьянка Немедленного Удовольствия, но она была милее всех на свете. С постоянно маячащими дедлайнами, Панический Монстр никогда не спал и Обезьянка знала об этом. Она конечно постоянно отвлекала, но не была за главного.

Мой мозг в школе:

Введение

Не в коем случае не хочу утверждать, что это гайд по тому, как вводить Scrum, — это лишь опыт введения и адаптирования Scrum’а под нужды одной компании. Данный опыт может быть интересен/полезен, как новичкам: основные наводки, этапы, циклы и т.п., так и профессионалам: обсудить что пошло не так, чего делать не стоило и т.п. Подчеркну, то что у нас вышло — это лишь нечто напоминающее Scrum.

Привет! Меня зовут Илья Кацев, и я представляю небольшое исследовательское подразделение в отделе тестирования в Яндексе. Вы уже могли читать о нашем экспериментальном проекте Роботестер — роботе, который умеет проделывать за тестировщика заметную часть рутинной работы.

Наша основная цель — изобрести принципиально новые подходы для нахождения ошибок в Яндексе. Я очень люблю порассуждать на тему того, какая часть работы в будущем ляжет на плечи роботов. Они уже отлично пишут спортивные репортажи и переносят грузы для солдат. И вообще мне кажется, что человеческий прогресс непосредственно зависит от того объема работы, который мы сможем передать роботам — у людей в этом случае появляется свободное время и они придумывают новые крутые штуки.


Есть такой тезис, сторонником которого я лично являюсь, — любую ошибку, которую может заметить неподготовленный пользователь, может обнаружить и робот. Именно это мы и попытались проверить. Но тут возникает вопрос: что именно человек считает ошибкой?

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

16 апреля открылся новый набор в Школу анализа данных Яндекса, который продлится до 15 мая. В этом посте я хочу рассказать вам, как сложилась судьба тех, кто уже закончил ШАД, а также впервые публично разберу все задания нашего письменного вступительного экзамена. Как всегда, желающим надо будет заполнить анкету и выполнить задание на сайте Школы, сдать письменный экзамен и пройти собеседование.

Кстати, если у вас есть знакомые или их дети, которым рано идти в ШАД, но которые подают надежды, расскажите им о факультете Computer Science, который открывается в этом году в Высшей школе экономики при участии Яндекса. Во многом он будет расти из Школы анализа данных, но в неё мы принимаем студентов и выпускников. Поэтому если вы абитуриент, то приходите 27 апреля на презентацию этого факультета, где ректор НИУ ВШЭ Ярослав Кузьминов и сооснователь Яндекса Аркадий Волож расскажут о нём все подробности. Мы всех приглашаем.

Истории: одна о гуглере и одна — о сотруднике Яндекса

С момента создания ШАД её закончили 260 специалистов в области computer science. Мы попросили двух выпускников Школы рассказать о том, что им дало обучение в ней, и дать несколько советов тем, кто решил поступать.

Андрей Петров, разработчик в мюнхенском офисе Google.

Когда я был студентом, у меня сложилась иллюзия, что программировать я уже умею, а Computer Science — это просто. Действительно, ведь я создавал сайты с динамическим контентом, писал игры, получал призы на олимпиадах и без проблем сдавал экзамены в университете. Однако это было лишь хобби, а я был любителем. Чтобы начать путь профессионала, я пошёл в школу Яндекса.