Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. На Хабре не так много материалов по данной дисциплине. К примеру, по управлению проектами – на порядок больше. Но выложенные недавно две статьи (раз и два), похоже, вызвали интерес, посему я тоже хотел бы внести свой скромный вклад. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.

Воодушевившись вашими отзывами к моим предыдущим постам: «Тур по Hacker Dojo» и «Видеоинтервью с Максом Скибинским», я решил выложить ещё один репортаж из Кремниевой Долины. На этот раз мы побывали в стартап-акселераторе Blackbox, который ориентирован на зарубежные стартапы, в т.ч. и из России, помогая им выйти на глобальный рынок. В частности, на одном из мероприятий Blackbox познакомились друг с другом русские основатели Virool, позже они успешно прошли через YCombinator — топовый стартап-акселератор. Под катом больше информации и интервью с основателем.

По материалам нашего доклада на РИТ2013.

В цифрах:

• $4500 – «топовая» зарплата разработчика в Киеве. Выше единицы
• Толковые разработчики с 3+ лет опыта могут получать $2500-4000
• Зарплаты диктует спрос на мировом рынке труда (аутсорсинг)
• $1,5 миллиарда заработали компании-аутсорсеры в 2012
• В пяти крупнейших компаниях работает 10 тыс. программистов (аутсорс)
• 40% разрабочтиков работают в Киеве
• Львов и Одесса догоняют Киев по зарплатам, Харьков и Днепропетровск отстают на 20-30%

Удивительно, что никто так и не осветил это событие. Неделю назад в Киеве прошла сходка-конференция «Games Night». Событие было разбито на две части: блок мини-докладов (по 5-10 минут каждый) и круглый стол, где докладчики отвечали на вопросы аудитории (которой собралось неожиданно много). А так же — свободное общение. Вход был свободный.

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

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

Докладов было 11:

• Андрей Арутюнян (Colibri Games) — о том, как команда из 3-х человек сделала свою игру
• Андрей Прохоров (4A Games) — авторы серии игр Metro и т.п.
• Артем Мироновский (Nival Red) — про то, как команде пойти под крыло гиганта Nival
• Олег Яворский (Vostok Games) — про то, как авторы S.T.A.L.K.E.R. искали финансирование на сиквел
• Игорь Карев (Tatem Games) — авторы «Анабиоза» и многих друих игр
• Кен Ливер (Eastlabs) — инкубатор игровых стартапов
• Олег Клаповский (GOG.com) — 3-я по масштабу платформа после Steam и Origin
• Евгений Жуков (Digitilus) — про то, как и когда выходить на Kickstarter
• Олег Придюк (Unity) — про то, как команда из 3х человек в гараже на деньги одного из родителей написала всемирно известный движок
• Андрей Ионес (Saber Interactive) — о разработке на консолях
• Сергей Климов (Daedalic) — про квесты и сторителлинг в играх

Видео выступлений:

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

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

Нас тут почти 300 000, и подавляющая часть так или иначе состоялись как специалисты в своей области. Думаю что немалому числу ХабраЖителей было-бы интересно в том числе и стать инвесторами в некоторые публикации, либо просто, при возможности чуть-чуть помочь.

Но потянуть по-отдельности (либо небольшой группой) серьёзный проект как по-финансам далеко не каждый сможет. А вот скинуться группой, например по 100 рублей в интересную тему, и в случае удачи — получать (пусть и по 10 копеек) каждый месяц, ну или просто и безвоздмездно подарить их на действительно интересную тему думаю было-бы интересно

От переводчика

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

Снова прошу прощения за отсутствие перевода словосочетания “computer science”.

Кратко

• Боритесь за закон Парето, следите за тем, чтобы 20% вашего труда давало вам 80% результата;
• Расставляйте приоритеты, ведь минимализм нужен для того, чтобы делать то, что нужно, а не распыляться по мелочам;
• Лучшее — враг хорошего: сначала просто сделайте, потом сделайте правильно, потом сделайте лучше;
• Убивайте в зародыше, не бойтесь начать всё сначала. Чем быстрее ошибётесь, тем быстрее научитесь;
• Повышайте свою ценность. Постоянно думайте о том, чем можно помочь команде, — и развивайтесь в этом направлении;
• Сперва основы. Мыслите последовательно, ориентируясь на лучшие практики мира Computer Science;
• Посмотрите с разных сторон. Простое получается тяжелее, чем сложное, поэтому включайте воображение;
• Синтаксис — основа взаимодействия. Мы пишем код для людей, а не для машин;
• Не запутывайте. Старайтесь проектировать слоями, по мере возможности не зависящими друг от друга;
• Вычищайте оставленное-на-всякий-случай. Минимализм борется с отвлекающим от основного.

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

Поэтому мы сделали небольшой сервис для облегчения поисков инвестиций для ИТ-стартапов.

Мы в Alconost предоставляем услуги создания и ведения контекстной рекламы и, по долгу службы, иногда занимаемся разработкой посадочных страниц (landing pages). Мы были очень рады найти и перевести статью, в которой автор изложил все требования, которым такая страница должна соответствовать. Но есть в этой статье и большой минус. Пунктов аж 50, каждый можно отметить в чеклисте, но после доступен лишь результат в баллах, которым можно разве что похвастаться перед друзьями.

Мы против таких способов анализа информации. Потому каждый желающий может скачать подготовленную нами гуглотаблицу, ответить на вопросы “Да” или ”Нет”, отфильтровать ответы и получить результат и план действий.

Те, кому в гуглотаблицу не хочется, просим под кат. Там перевод.

Проверьте свой проект: вы летите или думаете, что летите?

Ниже вопросы, которые стоит задавать себе на старте проекта и время от времени на его протяжении.

Контрольные вопросы на старте проекта:

1. Что конкретно нужно сделать на текущем этапе? В целом? Есть ли чётко определённые цели каждого этапа? Как вы определите, что цели достигнуты? Соответствует ли текущий статус заявленным планам и целям или их необходимо корректировать?
2. Реалистичны ли эти цели?
3. Что случится, если цели не будут достигнуты в срок? Каков план действий?
4. Насколько этот проект значим? Например, зависит ли от него место вашей компании на рынке?
5. Какую выгоду вам, обществу и инвесторам принесёт проект?
6. Достаточно ли хорошо спланирован проект? Все ли в вашей команде понимают пункты плана одинаково?
7. Нужны ли внешние эксперты, например, юристы?
8. Есть ли у команды опыт работы вместе? Кто будет координировать команду? Важно ли для проекта работать именно вместе — или возможен труд одиночек? Отвечает ли каждый член команды за работу всех остальных?
9. Можно ли сократить размер команды? Если нет, то почему? Если да, то почему это не сделано?
10. Как вы будете компенсировать форс-мажоры с персоналом, например, что случится, если ваш ведущий разработчик сломает руку?

Согласно данным AppAnnie почти весь рост выручки от приложений за последний год пришелся на in-app purchases. Но вызвано ли это только с тем, что данная бизнес-модель стала очень популярной? Или имеет место быть гиперконцетрация выручки у топовых паблишеров, которые в большинстве своем предпочитают free-to-play модель?

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

Если исключить разработчиков топовых приложений (тех, кто зарабатывает с приложения более $50 тысяч в месяц и имеет более 500 тысяч активных пользователей) окажется, что одним из важнейших аспектов стало привлечение пользователей и последующее их удержание. Тем более, что средняя выручка с одного активного пользователя довольно статична вне зависимости от модели монетизации.

Это заметка о подходе к реализации автоматизации механизма psd to html.

В этом посте я расскажу реальную историю о том как четыре человека (экспат-проказник, москвич, лимитчик да косолапый мишка) договорились о принципах партнёрства, закрепили эти договорённости простым письмом по электронной почте и, доверившись друг другу, за 9 месяцев географически-распределённой работы приблизились к своей мечте о независимости. Лично у меня эта мечта зародилась давно, но окончательно сформулировалась после прочтения «Четырёхчасовой рабочей недели» Тима Ферриса: идея о том, что надо создавать продукт, а не просто работать за зарплату, стала просто навязчивой.

Немного предыстории. Три года назад я поставил крест на своём предыдущем двухгодичном самоокупаемом, но слабо растущем проекте и начал регистрировать домены для нового: MyClasses.org — сеть локальных справочников (уровня города) о всевозможных курсах и уроках. На сайтах организуется процесс общения между школами, учителями и учениками. Этакая смесь Yellow pages + CMS + CRM + Feedback/Review + Social network. Локально-глобального масштаба.


Регистрировал домены я много, увлечённо и постоянно. Домейнерство, не в прямом смысле этого слова, — моя слабость — появилась идея и бац! — надо срочно зарегистрировать домен! Потом ажиотаж проходит, и появляется понимание что ни сил, ни времени, ни достаточных перспектив нет. Но домены остаются. Иногда их удавалось продать (3 раза по запросу, сам никогда не выставляю на продажу, лучшая сделка — $2.200, всего на $3.000 — не разбогатеешь). Но в этот раз всё было не так.

Очередная авантюра подкупала целым набором благоприятных факторов:

Тестирование является важной составляющей процесса разработки приложения. Для Android тестирование особенно важно, так как устройства сильно отличаются друг от друга:

• Размером и разрешением экрана.
• Версией Android.
• Форм-фактором.
• Системой команд процессора.
• Наличием фронтальной камеры, NFC, внешней клавиатуры, и т.д.

Поэтому тестировать приложение приходится на множестве устройств.
В процесс тестирования входят различные виды тестирования. Рассмотрим, как происходит процесс функционального тестирования приложения вручную. Тестировщик устанавливает на устройство приложение, вдумчиво проверяет всю функциональность, затем возвращает устройство в первоначальное состояние. И так для каждого приложения и каждого устройства. Очевидный недостаток такого способа – большие затраты времени для регулярного тестирования.
Очевидный плюс автоматизированного тестирования – его можно регулярно проводить без особых затрат. Например, каждую ночь тестировать свежий билд приложения на всем множестве имеющихся устройств, а утром анализировать результаты и исправлять ошибки.
В данной заметке будут рассмотрены средства реализации автоматического тестирования. Рассматриваются только инструменты, входящие в Android SDK или распространяющиеся под Open Source лицензией.

За последние полгода мне удалось побывать на двух стартап-конкурсах — DOU Mixer и Garage48. В первом команда формировалась “на лету”, что внесло определенную избыточность и путаницу ролей. Поэтому, во втором мы решили участвовать укомплектованным еще до его начала составом.

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

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

Как в фильме Начало (Inсeption), реальность в продуктовой разработке имеет определенную вложенность слоев. В зависимости от того, какая роль вам выпала, ваше “начало” в проекте может произойти раньше или позже, но всегда приятнее быть в числе создателей новой реальности, не так ли?

Эта статья — вступительная часть к трилогии о том, что собой представляет в гибкой продуктовой разработке:

• Готовность Начать
• Готовность Завершить
• Готовность Выпустить

Первая часть будет посвящена процессу открытия продукта (Product Discovery), вторая — процессу разработки продукта (Agile Delivery), третья — формированию цикла этих двух процессов, с обратной связью от рынка (Business Development). Здесь же, в начале, я задам общие рамки ролей и процессов, в которые буду углубляться в следующих частях.

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

Весной 2012 г., Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

Один из студентов лекции записывал и выложил транскипт. В данном хабратопике SemenOk2 переводит одинадцатое занятие. Редактор Astropilot.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

В одиннадцатой лекции рассказывается о секретах. Остались ли в мире ещё секреты или уже нет? Раскрывать найденный вами секрет перед всеми или нет? Будет немного о физике, террористах, фундаменталистах, конспирологах, географии и психологии.

Мы делаем крупную международную IT-конференцию. Вторую.
Сейчас, когда уже много сделано и можно оценивать первые результаты, я решила поделиться нашими наработками, находками и ошибками в этом неоднозначном деле.
Если вы как-то связаны с организацией любого мероприятия для IT-аудитории или только подумываете сделать что-то такое, статья будет вам полезна. Возможно, она убедит вас никогда за это не браться.
У меня получилось вывести 17 моралей с картинками, примерами и конкретным описанием допущенных нами ошибок. Почему мы не боимся об этом открыто рассказывать? Потому что это нас не ослабит, а к следующему году идеи будут новыми.
Тематика конференции в 2013 году – Деньги и управление в IT. Так что расскажу и о деньгах, и об особенностях управления, с которыми оказалась связана конференция.
Идеи, которые описаны в статье, – результат работы команд организаторов прошлогодней и нынешней конференции.

Прошлой осенью, вернувшись из отпуска, я обнаружил, что Дехана, наш Product Manager в UserVoice, заменила мой любимый «Roadmap» в Google Docs на доску Trello.

Моя первоначальная реакция на такие перемены была отнюдь не положительной. Проблема заключалась не в самом Trello, а в том, как мы им пользовались. Trello – это ОЧЕНЬ открытый проект. Не существует единственного “правильного” способа работы в Trello, поэтому, чтобы чувствовать себя в нем как дома, вам потребуется время для настройки «под себя».

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

Переведено в Alconost. Часть 1 — habrahabr.ru/company/alconost/blog/170201

7. Презентуйте и обсуждайте документы, а не слайд-шоу

В интервью Чарли Роузу Безос говорит: «Обычно на корпоративном собрании кто-то один выходит вперед и представляет общему вниманию… что-то вроде слайд-шоу. С нашей точки зрения… таким образом вы получаете очень мало информации, вместо нее вам достаются только тезисы. Это облегчает задачу тому, кто проводит презентацию, но усложняет понимание тем, кто его слушает. Поэтому вместо этого мы на всех наших собраниях рассматриваем подготовленный заранее документ — 6-страничную повествовательную записку. И вот, когда вам приходится выписывать свои идеи в виде законченных предложений и полновесных абзацев, это заставляет вас думать яснее и четче».