«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера


Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Хотелось бы коснуться проблемы выбора программного обеспечения для тех, кто сам не управляет проектами, а является начальником руководителей проектов по разработки ПО. Например, это может быть руководитель проектного офиса или руководитель департамента разработки программного обеспечения (или как там оно может называться). В общем – это человек, которые сам напрямую не управляет проектами, но должен помогать это делать другим. Что такому начальнику хочется знать:

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

Хочу поделиться тем, что удалось найти.
Исследование Интернета показало, что такого сорта ПО можно разделить на два класса:

• Полнофункциональные программы управления проектами.
• Программы управления несколькими проектами.

Рассмотрим их подробнее.

Обратили внимание, что доля поискового трафика Яндекса на Кабанчике значительно меньше, нежели доля Google. Т.е. значительно меньше, чем среднее соотношение трафика Yandex/Google по рынку.

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

Общие отличия Google от Yandex

• Возраст сайта больше важен для Yandex.
• Продвигаться по НЧ намного легче в Яндексе. Для этого достаточно писать качественный уникальный контент. В Google без ссылок на страницу продвигать НЧ тяжко. Для СЧ и НЧ Яндексу нужны трастовые доноры.
• Скорость индексации сайта в Яндекса в разы медленнее, нежели у Google: 8-10 дней против 1-2.
• Частое обновления контента влияет на траст в Google. Яндекс любит старые уникальные тексты.
• По ВЧ запросам в ТОПе Яндекса можно видеть в основном главные страницы сайтов. В Google — чаще внутренние страницы.
• На одной странице поиска Google может находится 5 ссылок с одного сайта. в Яндексе — только одна страница.
• На Яндекс легче влиять с помощью поведенческих факторов, нежели на Google.
• Google далеко не всегда обращает внимание на запрет к индексации в robots.txt.
• Скорость загрузки страниц более важна для Google. Он не пускает в ТОП медленные сайты. Для Яндекса скорость загрузки сайта не так важна.
• Яндекс больше любит поддомены для региональных запросов. Т.е. для продвижения в другом городе лучше использовать домен gorod.site.com/…
• Для Яндекса имеет большое значение нахождение сайта в Яндекс.Каталоге.

Внутренняя оптимизация

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

О системе

Фирма, в которой я работаю, разработала свою трейдинговую платформу типа MTF. В этой системе ежесекундно производятся десятки тысяч торговых операций, и с помощью паттерна Disruptor, средняя скорость выполнения трейда не превышает 20.5 миллисекунд. В проекте задействованы сложнейшие интеграции с третьими сторонами — крупными банками, Лондонским Домом Клиринга LCH и другими корпорациями.

На разработку проекта ушло около 3 лет и команда из примерно 20 инженеров. В проекте нету и не было ни одного руководителя проекта, координатора, планов проекта, диаграмм Гантта, документов архитектуры, спецификаций требований, и планов тестирования.

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

Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009, где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи — это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.

Принято считать, что информационные технологии в государственных ведомствах приживаются тяжелее, и для этого мнения есть ряд объективных причин. Однако, как говорил Альф: «Вы не любите котов? Значит, вы не умеете их готовить!». И сегодня мы хотим поговорить о том, как отличаются проекты в госкомпаниях с точки зрения бизнес-IT интегратора, и для каких целей госы создают большие хранилища для аналитических проектов.

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

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

Сразу скажу — топик — для тех, кто не разобрался что такое MapReduce. Для тех, кто разобрался — полезного тут ничего не будет.

Начнем с того как собственно родилась лично у меня идея MapReduce (хотя я и не знал, что он так называется, и, разумеется, пришла она мне куда позже чем Гугловсцам).

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

Как посчитать все слова в Википедии (неправильный подход)

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

В самом простом случае мы можем завести хеш (dict, map, hash, ассоциативный массив, array() в PHP) и считать в нем слова.

$dict['word1'] += 1

Но что делать когда память под хеш кончится, а мы посчитали только одну сотую всех слов?

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



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

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

В своей работе мне постоянно приходится делать оценки для проектов, задач и работ, которые еще только предстоит выполнить, и поэтому точно измерить их невозможно. Недавно один из крупных клиентов Аксенчер, обратился в нашу компанию с просьбой помочь в разработке более систематизированной методики подготовки таких оценок. Проект так и не случился, но материалы, которые я собрал, оказались чрезвычайно полезными для меня самого. Я смог понять, почему, несмотря на планирование проектов по аккуратно выверенным оценкам, люди почти всегда превышают бюджет. Понял, что, гарантируя вписаться в бюджет с вероятностью в 95%, подрядчики гарантируют, что с вероятностью 95% им столько времени и денег не нужно. Ниже я описал свои выкладки, которые, возможно, вас тоже заинтересуют.

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


Подпись же картинке не нужна, правда?

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

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

И тут начинается самое неприятное.

Вводная

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

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

Вступление

1. Моделирование транспортных потоков стало одной из лидирующих проблем в науке, чуть ли не с появления первых автомобилей. Считается, что родоначальником данной отрасли является учёный ещё из царской России Дубелир со своей книгой «Городские улицы и мостовые» (1912 год). За 100 лет непрерывных исследований выработалось много хороших моделей, которые помогают сегодня строить качественные и быстрые дороги. Но если Вы думаете, что не осталось нерешённых вопросов, Вы сильно ошибаетесь, ведь до сих пор светлые умы нашей планеты ломают головы над решениями задач, о которых иногда спрашивают даже дети. Например, как настроить светофор так, чтобы около него не образовывалась пробка?

TL;DR: К концу этого эссе я надеюсь убедить вас в следующих фактах. Во-первых, что современные десктопные операционные системы никуда не годятся. Они раздутые, тормознутые и напичканы легаси-хламом, а кое-как работают только благодаря закону Мура. Во-вторых, что инновации в десктопных ОС прекратились около 15 лет назад, а основные игроки вряд ли собираются много вкладывать в них снова. И наконец, я надеюсь убедить вас, что мы можем и должны начать с нуля, усвоив уроки прошлого.

«Современные» десктопные ОС раздуты

Возьмём Raspberry Pi. За 35 долларов я могу купить отличный компьютер с четырьмя процессорными ядрами, каждое на частоте более гигагерца. У него также есть 3D-ускоритель, гагабайт оперативки, встроенные WiFi с Bluetooth и Ethernet. За 35 баксов! И всё-таки для многих задач, которые я хочу на нём запустить, Raspberry Pi ничем не лучше компьютера на 66 мегагерц, который был у меня в колледже.

За свои 12 лет работы в сфере разработки ПО, мне посчастливилось поработать в команде только два раза. Хотя я сменил порядка десяти мест работы. Но попробовав раз, ем и сейчас… Т.к. я не жадный, и готов своими достижениями делиться с сообществом, то решил я предпринять попытку вывести из равновесия неумных руководителей, которые до сих пор не осознали важность команды, а также тех руководителей, которые профессионально занимаются самообманом — мол, они строят команду, а на деле — тьфу, а не команда.

Проблемы git-flow

Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю о git-flow. Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится чем-то вроде стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

Миллениалы во многом уникальны — это те, кто росли с игровым джойстиком в руках. Теперь они становятся преобладающим поколением, на которое начинает ориентироваться все окружение. Вместе с Миллениалами в культуру проникает геймификация, которая пускает корни во всех областях, и, в первую очередь, маркетинге и торговле. МЕГА успешно применяет новые технологии на своих площадках, а что из этого получается и как геймификация влияет на поведение поколения Y, мы расскажем в нашей статье. Но начнем мы с теории. Точнее, с «Теории поколений».

Часть 1. Lead Generation


Практически в любой организации в процессе работы с клиентами можно выделить три основных этапа:

Первый этап Lead Generation – создание потока потенциальных клиентов. Не все клиенты одинаково полезны для нашего бизнеса, тратить время на бесперспективных клиентов смысла нет. Не надо бежать за «бумажным зайцем», продавцы должны концентрироваться только на тех запросах, которые принесут выручку, это особенно важно в B2B продажах. Если у вас стоимость транзакции маленькая, и клиент достаточно быстро принимает решение, то скорее всего вам нужен один сквозной процесс заказа, где у продавца будут преднастроенные задачи, которые он должен выполнить, чтобы потенциальный клиент с максимальной долей вероятности конвертировался в клиента.

С момента описания первого искусственного нейрона Уорреном Мак-Каллоком и Уолтером Питтсом прошло более пятидесяти лет. С тех пор многое изменилось, и сегодня нейросетевые алгоритмы применяются повсеместно. И хотя нейронные сети способны на многое, исследователи при работе с ними сталкиваются с рядом трудностей: от переобучения до проблемы «черного ящика».

Если термины «катастрофическая забывчивость» и «регуляризация весов» вам пока ни о чем не говорят, читайте дальше: попробуем разобраться во всем по порядку.

Первая часть нашего гайда была посвящена интересной задаче машинного обучения – распознаванию пола по голосу. Мы описали общий подход к большинству задач speech processing и с помощью случайного леса, обученного на статистиках акустических признаков, решили задачу с довольно большой точностью – 98,4% верно классифицированных аудиофрагментов.

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

В каком-то смысле эта ступень избыточна: пол человека не меняется во время разговора (по крайней мере, на текущем этапе развития и в заданных стандартных условиях), поэтому рассчитывать на увеличение точности не стоит. Но в академических целях мы попробуем.