Уже давно крутятся мысли по поводу пользовательских интерфейсах и о их деградации развитии конечно же, ими то я и хочу сегодня поделиться. Многие помнят старые интерфейсы с псевдографикой в текстовом режиме со скупым функционалом и ограниченным юзабилити. Потом им на смену пришли оконные интерфейсы в графическом режиме и теперь уже веб-интерфейсы. Но повысилась ли скорость работы потребителей прикладных программ, пользователей и операторов ввода? Повысилась ли скорость разработки экранов и отчетов? Многие скажут Вам твердое «нет» — средняя производительность программистов и пользователей снижалась с каждым новым шагом технологий вперед. И для этого есть ряд объективных причин. Кроме них мы сегодня остановимся и на том, как же все-таки поднять сею производительность.

Удивительно, но совершенно незамеченными остались взлёт и падение рынка с оборотом в $50,000,000 в месяц. Рынка стимулированных установок для iOS.

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

Система попадания в рейтинг очень проста¹. Определенное время рейтинг в AppStore строился на количестве установок того или иного приложения, а значит, в топе был тот, кто смог проплатить наибольшее число установок, используя медийный ресурс или, что чаще, рекламные сети.

О рекламных сетях и о занятной ситуации на этом рынке пойдёт речь далее.

Свершилось! Наша игра Viking Tales успешно рассмотрена командой приёмки Appstore и поступила в продажу во все магазины планеты.

Как всегда после каждой презентации компании с 1 Infinite Loop интернет заполняется «белым шумом», состоящим как из восторженных воплей, так и из криков ненависти.

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

• Retina Display + iBooks vs. Amazon + Kindle/Barnes&Noble + Nook/...
• 1 млрд долларов vs. Android Marketplace.
• FaceTime vs. Skype
• Гироскоп vs. Nintendo DS/Sony PSP

Те, кто еще не понял, прошу под кат

Начало

Я всегда интересовался мобильными платформами. Вообще мобильных аппаратов я за свою жизнь поимел, так сказать, много:

• Java ME — Samsung SGH i600, Samsung SGH C100 (прошлый век),
• Palm OS — Sony TJ37,
• Windows Mobile — HP iPAQ HW 6515, iMate SP5 (один из лучших телефонов всех времен и народов), Fujitsu-Siemens Pocket Loox c550 (один из лучших коммуникаторов всех времен и народов),
• Symbian — Nokia E51 (но симбиан мне сразу не понравился).

Возможно я что-то пропустил, но это скорее по-тому, что эти пропущенные гаджеты даже не стоят упоминания.

И наконец iPhone. Вообще в тот день когда прошла презентация устройства я зарекся смотреть эту презентацию. Потому, что боялся что айФон станет моим наваждением. Я знал, что это будет нечто грандиозное. Но через год я все-же посмотрел презентацию и купил телефон.

Как опубликовать обзор вашего стартапа на TechCrunch? Что круче — Хабр или TechCrunch? Какой он, TechCrunch effect?



В конце прошлого года мы запустили проект TradingView, о чем незамедлительно поставили в известность Хабр. Чуть более месяца назад о нас написал TechCrunch. Под катом детальная информация из первых рук о результатах этих экспериментов и ответы вопросы.

Единственный интуитивно-понятный интерфейс — это женская грудь, всему остальному нужно учиться. Эта народная мудрость пришла ко мне сегодня утром, когда я в деталях и красках рассказывал третьему по счету коллеге, чем resolved отличается от closed и как делать log work, чтобы руководству не было потом мучительно больно. В этой статье я попробую на примере нескольких зарисовок обрисовать возможные варианты использования системы управления задачами на примере популярной Jira при ежедневной работе. Приемы, конечно, не единственно возможные — но они достаточно просты, универсальны и применимы не только к Jira, но и к большинству популярных систем управления задачами — Redmine, Trac, Bugzilla и прочим.

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

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

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

На написание поста меня сподвигла найденная на просторах хабра ссылочка на сайт с альтернативами Basecamp. Уверен многие уже заходили и смотрели предлагаемые альтернативы. Я же решил просмотреть их все. По результатам просмотра было выбрано 4 (+ 1 бонусная) системы управления проектами, которые можно назвать реальными альтернативами Basecamp. Из них три являются чуть менее, чем полностью неизвестными на просторах хабра (поиск дает практически нулевой результат), что дает мне надежду на то, что данный топик сообщит вам что-то новое. Критерии выбора и краткий обзор систем под катом (осторожно скриншотный трафик ~0.5 Mb).

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

Что же такое проект?

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

Четвертые обладают оригинальным чувством юмора и способностью видеть вещи под другим углом. Пятые могут просочиться на любые мероприятия и взять с собой друзей. А шестые сидя в офисе постоянно ворчат и никого не любят. Всех этих людей объединяет одно — они не поднимают флажок.

Вместо введения

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

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

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

Так вот, советы как завалить проект:

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

2) Концепт не нужен, зачем тратить время? Главное, начать как можно быстрей писать код, а идеи и концепт обязательно придут в пути. Кто быстрей начнёт программировать, сможет забронировать самые интересные задания.

3) Очень важно менять существенные вещи примерно в середине проекта, а лучше несколько раз. Ведь нужно было срочно программировать, и выбрали не ту технологию, не тот способ, 3D графику вместо 2D.

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

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

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

Это попытка на картинках порассуждать, почему проекты так сложно выпускать в срок, и как задание приоритетов может улучшить ситуацию.

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

На этом этапе проект для нас — осязаемое, но все еще довольно бесформенное облако.

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

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

В этом топике — обещанный обзор разных настольных игр.

— Первая часть — это «портированные» версии известных компьютерных (по сюжету Starcraft, Warcraft, Civilization, Age of Empires, Master of Orion, Doom)
— Вторая часть — игры, которые интересны многим хабражителям, судя по комментариям к прошлым топикам.
— В комментариях предлагаю делиться информацией об интересных играх: думаю, многие смогут подсказать нечто необычное в плане поиграть или же предупредить от напрасной покупки.
— Топик будет интересен тем, кто хочет понять, что популярно на рынке, вкратце посмотреть товар для магазина и тем, кому просто интересно, что же там вообще есть из настольных игр для себя, компании или в подарок.
— В конце есть приятный бонус хабрачитателям.

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

Для начала вспомним отличия традиционной системы управления — репрессивной, от гуманной и творческой Agile модели.

Репрессивная модель управления

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

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



Модель, разумеется, очень эффективна на коротких и средних дистанциях. Еще бы — вспомним Фашистскую Германию, ее бурный рост и развитие. Но… модель имеет косяки, т.к. «посеявший ветер, пожнёт бурю» (чем заканчивает владыка ситх и его последователи, мы знаем :-)).