Моя работа — ждать IT-катастрофы

Моя работа — ждать IT катастрофы

Лучшее, что может случиться, — это если результаты того, что я делаю, никогда и никому не пригодятся.

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

Вот, например, знаете что будет, если землетрясение уничтожит основной московский ЦОД?

  1. Сработает автоматика и перебросит часть сервисов на другие ЦОДы. Всё то, что было active-active, продолжит работу (это базовые функции сети, вроде звонков и SMS).
  2. Затем включается базовый сценарий реакции. Сразу после происшествия формируются команды восстановления из специально обученных людей на объекте, имеющих подготовку по всем аспектам работы этого объекта. Например, из инженера на смене, охранника, системного администратора и так далее. Они бросают все свои текущие дела и занимаются только восстановлением.
  3. В течение первых 10 минут «бронзовая» команда восстановления анализирует ситуацию. На 11-й минуте руководитель команды докладывает команде более высокого уровня («серебряной», как правило, не присутствующей на объекте), например, главному инженеру и руководителю подразделения.
  4. «Серебряная» команда принимает решение на своём уровне. В нашем случае проблема явно особенно важная, поэтому команда связывается с «золотой» командой — руководителями самого высокого уровня. На принятие решения о том, что ситуация является чрезвычайной, уходит ещё 10 минут (это очень быстро). В течение ещё 5 минут активируются составленные нами планы аварийного восстановления.
  5. Руководители «бронзовых» команд собирают людей и идут восстанавливать, что могут, на месте. Параллельно собирается кризисный комитет, включающий известных специалистов, описанных в плане на этот случай.
  6. Далее кризисный комитет взаимодействует с HR, PR, безопасниками и другими службами. В частности, совершенно точно PR к этому моменту будет остро нуждаться в информации — абоненты уже полчаса без мобильного интернета, нужно выступить с данными о сроках восстановления.
  7. Разворачивается резервная точка. В течение 20-30 минут восстанавливается инфраструктурный слой. Затем идет восстановление СУБД и там, где надо, восстановление из архива с ленты. Далее — восстановление приложений (от получаса до дня).
  8. Параллельно в течение первого часа проверяется, как всё переехало.
  9. Затем появляются детальные отчёты. План аварийного восстановления заканчивается, и мы снова «засыпаем» до следующей ситуации.

(далее…)

Как составить опрос по методу развития клиента (Customer Development) и выжать максимум из него

Как составить опрос по методу развития клиента (Customer Development) и выжать максимум из него

Управление стартапом подразумевает большой круг обязанностей. Маркетинг и продажи, любительский HR и бухгалтерский учет, разработка и проджект менеджмент, одним словом, вы должны быть мастером на все руки. Мы все понимаем важность подхода Бережливого стартапа (Lean Startup) и методов развития клиентов (Customer Development), однако, их трудно реализовать на практике. Кстати, если вы еще не наткнулись на CustDev.com, бегите туда прямо сейчас и хватайте книгу Brant’а и Patrick’а The Entrepreneur’s Guide to Customer Development (или русский перевод книги — Стартап вокруг клиента).

Как только вы пообещали себе «выбраться из офиса», чтобы поговорить со своими клиентами и по-настоящему исследовать вопрос о востребованности предлагаемого продукта на рынке (Profit-Market Fit), очень важно выжать максимум из этого мероприятия. Для новичков в методологии развития клиента одной из наиболее сложных вещей является составление опросов, поэтому я бы хотел поделиться тем, как я структурирую опросы для достижения максимальной отдачи от них.
(далее…)

Как стать предпринимателем? Четыре буквы: JFDI

В офисе моей первой компании висело изображение с логотипом Nike и заглавными буквами JFDI. (JFDI расшифровывается как «Just Frickin’ Do It» — «просто, блин, сделай это». Если не совсем очевидно, аббревиатура обыгрывает слоган компании Nike «Just Do It» — «просто сделай это»). Я уверен в том, что для успеха в бизнесе нужно быть в состоянии сделать много чего. Вы постоянно должны принимать решения, а информации никогда не хватает. Это парализует многих. Но не вас.

Переведено в Alconost Translations.

image
(далее…)

Квалиметрический подход к рейтингованию стартапов

В 20 веке перед экспертами различных стран стояла острейшая проблема нахождения надежной методологии оценивания качества, в том числе результатов деятельности творческих коллективов, их работников, продукции, проектов и услуг. В результате в 1968 году в мире появилась научная дисциплина квалиметрия [1], спрос на использование которой существенно вырос в последнее время в связи с бурным развитием интернета и в связи с расширением областей человеческой деятельности, для которых характерна квантификация методов, средств и способов исследований. Квалиметрический метод был разработан Г.Г.Азгальдовым [2] и развит в многочисленных трудах российских и зарубежных исследователей.

Одним из успешных примеров использования квалиметрического подхода при рейтинговании является Национальная премия в области франчайзинга «Золотой бренд» [3, c.121-143], подведение итогов в трех номинациях которой проводится с 2006 года по квалиметрической методике (в главной номинации использовался комплексный показатель — «интегральное качество»).

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

Индекс востребованности специалистов. Кого хотят работодатели?

Все говорят о том, как сильно нужны разработчики и как их не хватает. Когда мы начинали считать наш индекс, мы тоже так думали. Действительность оказалась немного сложнее и интереснее: разработчиков хотят, да. Но — далеко не всех одинаково.

Представляем наш первый рейтинг востребованности специалистов.

Предложений на одного кандидата Выборка (# кандидатов)
JavaScript 4.13 46
iOS 3.087 23
QA 3.045 22
PHP 2.928 111
C++ 2.717 53
Java 2.412 97
Android 2.321 28
Тимлид 2.138 29
Python 1.98 50
.NET 1.865 96
Менеджер проекта 1.091 22
Ruby 1 24

Данные по рынку труда в Киеве, на других рынках вероятно ситуация отличается. Но тендеции все равно интересны.

(далее…)

Можно ли нажиться на пользователях? 3 простых способа поднять монетизацию приложения

— Нюхни, нюхни, у тебя денежки есть?
— Нет…
— Вынюхни, вынюхни!!!

image

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

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

Итак — три простых шага, которые помогли нам повысить монетизацию приложения в полтора раза.

(далее…)

Как начать работать над личным проектом

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

Существует множество причин, из-за которых программист может начать работать над сторонним проектом. Это хороший способ держать руку на пульсе современных технологий, которые сейчас на пике популярности в отрасли. Это может помочь вам отточить свои навыки программирования. И это весело! Ну или должно быть весело.
Но то, что мы привыкли называть “жизнью” может не только усложнить вам завершение проекта, но даже не дать начать работать над ним. Мы часто тратим много времени чтобы придерживаться напряженного графика, и может показаться невозможным использовать хотя бы минутку для личного проекта.
Я начал работать на моим первым сайд-проектом два года назад, и я не эксперт в этом вопросе, чтобы это не значило. Спустя два года, я сделал несколько наблюдений о начале работы над сторонними проектами, которые я начал, почему я смог некоторые закончить, а некоторые нет. То, что я попытаюсь описать не претендует на новаторство, ни на пошаговое руководство, а является исключительно лишь наблюдениями, которые могут оказаться полезными.
(далее…)

Когда-то я говорил…

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

Когда-то я говорил, что на собеседование должен готовиться не только соискатель, но и интервьювер. Теперь я сам провожу собеседования, но после десятого интервью все соискатели выглядеть как китайцы – одинаково.

Когда-то я говорил, что опаздовать на встречи могут только пид$расы. Теперь я сам часто опаздываю на встречи, но в то же время не сплю с мужиками.

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

Программирование, быстрое и медленное: разработчики и психология самоуверенности

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

Но сначала история…

Это было <вставьте период времени, который не будет делать меня нелепо старым> в то время, когда я был молодым разработчиком (1). В колледже я был лучшим на занятиях по программированию, будучи младшим разработчиком, я мог взломать код и решить любую поставленную передо мной задачу быстрее, чем кто-либо ожидал. За выходные я мог изучить новый язык и продуктивно на нем работать (или, по крайней мере, мне так тогда казалось).

Таким образом, как и должно было произойти, у меня появился свой собственный проект. Менеджер по работе с крупными клиентами объяснил мне в общих чертах, чего хочет клиент, мы это обсудили, и я сказал: «На эту работу уйдет 3 недели.» «Хорошо», — ответил он. И так я приступил к программированию.

Как вы думаете, сколько времени у меня ушло на этот проект? Четыре недели? Может быть пять?

Мм, вообще-то: три месяца.

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

В один из таких черных периодов я решил, что Больше Никогда Не Буду Совершать Подобных Ошибок.

К сожалению, в ходе своей карьеры, я уяснил нечто очень тяжелое: я постоянно совершаю подобные ошибки.
(далее…)

Шпаргалка выступающего, или Как я делал свой первый доклад

Олег Громов выступает на конференции ДАМП-2013

Я уже 6 лет занимаюсь фронтенд-разработкой профессионально, и около 15 лет компьютерами в качестве хобби. Никогда в жизни мне не приходилось посещать конференции и, откровенно говоря, я стеснялся — сначала просто появляться на подобных мероприятиях, а до последнего момента и выступать. Как оказалось, напрасно, потому что выступать здорово!

В конце апреля Женя, коллега, подал идею съездить в Екатеринбург на Дамп — уральскую конференцию веб-разработчиков. Раз приключилась такая оказия, я подал заявку на выступление и начал выдумывать тему.

(далее…)