Чтобы Яндекс показал Ваш сайт в числе первых, нужно чтобы он максимально полно отвечал на запрос пользователя. И это будет уже половина успеха. Оставшаяся половина это удобство, техническая составляющая сайта и его простота. Ниже я привел чек-лист из 68 пунктов, который был разработан специально для системы управления задачами PTYSH, совместно с компанией DFAKTOR. А теперь я делюсь им с Вами. Кропотливое выполнение каждого пункта из данного чек-листа позволит вывести практически любой сайт на самый верх поисковой выдачи. Но придется как следует поработать. Начнем с самого малого.

Всё началось одним летним вечером, во время чтения книги эволюционного биолога Ричарда Докинза «Бог как иллюзия». Данная книга о религии, вере и атеизме, но автор кратко ссылается на другую книгу «Эгоистичный ген» и вводит одноимённое понятие. Меня долгое время восхищало изящество генетических алгоритмов. И вот, спустя месяц, в очередной раз пытаясь придумать какой-нибудь мини-проект, меня внезапно осенило – а что, если с помощью генетических алгоритмов симулировать эволюцию и посмотреть, что и как будет развиваться. Задача это сложная и на данном этапе развития IT, полагаю, нерешаемая, так что пришлось заняться чем-либо попроще. А именно, проверить гипотезу эгоистичного гена. Заинтересовавшихся, прошу под кат…

Иногда, открываешь какой-нибудь проект с историей и понимаешь, что история и у этого проекта была длинная… Да еще и авторы менялись, и видно, что у них был небольшой опыт.

В чем это выражается? — В том, что все части системы настолько переплетены, что невозможно оторвать один кусок и использовать где-то еще. Как результат, такой проект, конечно невозможно накрыть никакими модульными тестами кроме как приемочными со стороны группы QA. А значит, что со временем стоимость доработки будет возрастать, так как мы теряем уверенность в том, что наши изменения не поломают какие-то другие части.

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

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

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

Скорее всего, проблемы с рассылкой в какой-то мере есть у большинства стартапов. Чтобы помочь вам не наступить на наши грабли мы определили три основных «детских» ошибки, которые были нами допущены и хотим поделиться с вами путями их устранения.

Цель: Создание площадки взаимодействия и контроля между Руководителем предприятия и Главным бухгалтером/Операционным директором/Руководителем подразделения.

• Подцель 1: Контроль за расходованием средств. Взаимодействие CEO — CFO.
• Подцель 2: Контроль выполнения объемов производства. Взаимодействие CEO — COO.
• Подцель 3: Процесс согласования документов.

Пару месяцев назад я была на тренинге по Scrum. Делясь опытом с соучениками, упомянула, что у меня сейчас команда из десяти человек в восьми офисах. Мне не то, чтобы совсем не поверили, но к разговорам, что у нас нормальный процесс, отнеслись с, вероятно, оправданным скептицизмом.

Однако же, мы успешно делаем проекты командами, разделенными на 2-4 офиса, всего же у нас на данный момент десять офисов разработки, и, когда мы ищем человека в команду, обращаем внимание в первую очередь на его способности и человеческие качества, а уже во вторую — на место жительства. К тому же у нас в компании люди иногда кочуют между офисами, потому что так веселее. В общем-то, когда мы начали работу над нашим текущим проектом, у нас было всего четыре локации.

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

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

Итак, в чем проблема распределенной команды? Коммуникации. Затруднены коммуникации на всех уровнях, что порождает веер проблем. Та самая «транспортировка», которая упомянута как один из компонентов waste (потери) в концепции Lean Software Development.

Я для себя выделила три составляющие проблемы коммуникаций:

• Техническая: если человека рядом нет, к нему нельзя просто взять и подойти, чтобы обсудить какие-то текущие проблемы.
• Мотивационная: если у команды нет своей комнаты, где перед глазами есть доска со стикерами, списком проблем и остальной полезный контекст, фокус и приоритеты начинают «плыть».
• Психологическая: люди, которые не сидят рядом и не видятся каждое утро, обсуждая за кофе последние новости или успехи детей в школе, менее склонны прощать ошибки коллегам, особенно если про коллегу они знают только логин в системе контроля версий и e-mail. Может возникать концепция «мы и они» по отношению к коллегам из другого офиса и прочие неприятные штуки
• Отдельным пунктом стоит адаптация Scrum-активностей под распределенную команду.