Не так давно я запустил небольшой проект, призванный помочь «мобильным» людям объеденяться, общаться на форуме, меняться мыслями на хабраподобных блогах итп. Однако, как правильно было замечено в комментариях, проект якобы «мобильный», а с мобильных устройств он смотрится хреновенько, не смотря на валидную xhtml верстку итп. «Черт подери», — подумал я, включил свой FS loox n560 и начал потихоньку переверстывать темплейты для pda версии.
Сначала я думал обойтись подключением «handheld.css» и написанием КПК-ориентированных стилей, как я это делаю обычно для «печатных» версий. Но достаточно быстро понял, что не все проблемы можно решить с помощью CSS. Тем более принцип построения тех же «печатных» страниц сводится обычно к: «Это скрываем, это скрываем, это переносим сюда, это туда, а это тоже скрываем». Все же мы имеем дело с мобильными устройствами и грузить лишний траффик, чтобы в итоге не отображать его это глупо… В итоге пришел к тому, что следует не только CSS стили переписать, но и шаблоны переверстать. Начал с более маленького и простого проекта, чтобы попрактиковаться…

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

Этот принцип успешного продвижения на рынке различных мобильных гаджетов впервые пришел на ум Аарону Маркусу еще на рубеже 70-х годов прошлого века. Он первым понял, что пользовательский интерфейс – это главное, что требует постоянного усовершенствования для того, чтобы потребитель получал как минимум удовлетворительный, а как максимум положительный опыт использования того или иного товара или услуги.

Алекс Искольд, предприниматель и один из основных авторов известного блога Read/WriteWeb, опубликовал список полезных советов для стартапов. Этот список составлен по материалам многочисленных публикаций автора, он содержит 36 пунктов по пяти темам: разработка кода (8), инфраструктура веб-проекта (5), пиар (11), участие в конференциях (7), юридические и финансовые советы (5).

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

Итак, вот они:

Продолжаю публиковать некоторые материалы из своего блога IdeaBlog.ru, посвященного венчурным инвестициям, венчурным инвесторам и стартапам.

Небольшой анонс: на блоге в рубрике Venture Capitalist's Profile блога IdeaBlog.ru опубликована статья под названием "Профиль инвестора: венчурный фонд компании «ФИНАМ». Дмитрий Родионов", в которой, на основе интервью с руководителем проектов (венчурные инвестиции) Центра инвестиций в высокии технологии компании «Финам» Дмитрием Родионовым, раскрываются инвестиционные предпочтения венчурного фонда компании «Финам», его требования к проектам и к командам проектов, говорится по каким причинам отсеивается большинство соискателей инвестиций и т.д.

Когда стартапер задумывается о привлечении внешних инвестиций, всегда встает вопрос о подготовке бизнес-плана — в его отсутствие с инвесторами разговаривать, может, и можно, но дальше разговоров дело не пойдет. Многие считают, что бизнес-план для стартапа, особенно находящегося на pre-startup стадии развития — это фикция, что делать его не нужно, а, если и делать, то можно обойтись формальными словами. Однако такие стартаперы остаются, как правило, без инвестиций. Если, конечно, они не напали на какого-то лоха-инвестора: один из успешных российских стартаперов рассказывал мне о том, что среди бизнес-ангелов, которым он презентовал проект в рамках сотрудничества с одной из российских сетей бизнес-ангелов, были и любовницы олигархов — “настоящие блондинки” по его словам — которым их спонсоры дали денег с тем, чтобы те прикупили себе бизнес и занимались им, а не выносили бы мозг своим “папочкам” от безделья; так таким “инвесторшам”, по словам этого стартапера, важнее было, чтобы понравился сам стартапер, а не проект. Однако всем остальным инвесторам потребуется ваш бизнес-план, и изучать его они будут очень серьезно. Этот документ им нужен даже не столько для цифр окупаемости, которые вы там приводите, а для того, чтобы понять, насколько глубоко вы изучили рынок, на котором собираетесь действовать, и будет ли ваш продукт/услуга востребованы вашей целевой аудиторией, которая и должна приносить деньги стартапу. Поэтому к составлению бизнес-плана следует отнестись очень и очень серьезно. Это документ прежде всего является своеобразным вопросником для вас самих — достаточно ли вы изучили рынок, все ли продумали в своем проекте. Лично я всегда по своим новым проектам — неважно, собираюсь ли я привлекать инвестиции или нет — прежде, чем начать их реализацию, составляю бизнес-план — причем всегда с цифрами. Для себя и для лучшего понимания что я хочу, что мне предстоит сделать и смогу ли я это сделать сам либо мне придется кого-то привлекать. В 99% случаев те суммы, которые мне изначально кажутся достаточными для реализации проекта, возрастают в 2-3 раза — за счет додумывания тех мелочей, их которых, как известно, и складывается бизнес.

Когда я разговариваю с потенциальным менеджером проекта, я всегда задаю вопрос по процессу прохождения проекта. Все хорошие менеджеры рисуют его примерно одинаково, примерно так как написано в хороших умных книжках. Вот примерно как этот процесс должен проходить:

Проект инициирован и идет полным ходом.
Некая проектная документация для него уже составлена и подходит время для отрисовки дизайна. Менеджер ставит дизайнеру задачу, а через неделю забирает 10 прекрасно нарисованных макетов страниц. Дизайнер старался как мог и потому каждый пиксель в данном дизайне продуман и поставлен на нужное место.
Дизайн передается к верстальщику, который погружаясь в код старается заверстать великолепный дизайн дизайнера с точностью до пикселя. На выходе он по документации выдает 20 заверстанных страниц.
После чего дизайн поступает программистам. Которые собирают проект и теперь это уже не просто статичный дизайн — это работающий интернет-сайт.

Казалось бы просто, но.
Когда через несколько недель после начала сборки проекта до проекта добираются тестировщики, они хватаются за голову. В верстке обнаруживается десятки несоответствий дизайну. Баги сыплются на головы программистов и верстальщика. Следя за сборкой, дизайнер погружается в грусть все глубже и глубже, его состояние на границе отчаяния, а дизайн в забвении (как можно положить “это” в портфолио?!). Верстальщик не прекращает попыток фиксить баги, но они появляются быстрее, чем он успевает их читать.

Единственное, что имеет значение

Предыдущие части: Первая часть, Вторая часть, Третья часть

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

Но для начала немного теории.

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

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

Второй очевидный факт: существует огромное различие в трех главенствующих частях стартапов — командах, продуктах и рынке.

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

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

 

Фёдор Вирин: Самым интересным, по крайней мере для меня, докладом является доклад о юзабилити, и о том что это такое, Дмитрия Сатина, руководителя UsabilityLab.
Юзабилити – это странная штука. Компаний, которые занимаются юзабилити и только юзабилити в России три. Это UsabilityLab, Usethics и UIDesign. И всё! Ну и соответственно, Дмитрий Сатин, который руководит UsabilityLab, я думаю, более чем достойная кандидатура для рассказа о том, что такое юзабилити.

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

Для моего друга KamniumKamnium в связи с переходом на Битрикс стал актуальным вопрос управления проектом (за этот же нелюбимый многими хабралюдьми Битрикс ему понизили карму до такой стпени, что ему теперь не написать в блог).

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

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

В ответ на habrahabr.ru/blog/pm/27099.html хочу привести взгляд на ситуацию со стороны фрилансера.

За годы работы с заказчиками у меня скопилась маленькая “тележка” проблем при работе во фрилансе. Пришло время немного систематизировать эти знания. Приступим.

Проблема 1. Отсутствие техзадания.

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