Изображение сайта media.licdn.com

Как утверждает венчурный инвестор и программист Лео Половетс, в сегодняшнем мире Saas, API и облачной инфраструктуры проработанная техническая составляющая редко становится причиной успеха или провала программного продукта. Современные технологии теперь позволяют разработать его очень быстро с минимальными затратами. Казалось бы, это как раз то, что нужно стартаперам.

По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации. Большинство провалов случается в результате неверного позиционирования продукта, отсутствия грамотной маркетинговой стратегии, плохих специалистов по продажам, неверной бизнес-модели. Наличие или отсутствие высококвалифицированных инженеров практически не играет никакой роли, делают вывод исследователи.

Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений. Зато очевидным преимуществом этих компаний является удачная бизнес-модель. Вкупе с активным продвижением, эти сервисы смогли стать одними из самых востребованных и дорогих стартапов мира. Но вряд ли они нанимали десятки инженеров, чтобы разработать сервис и подготовить его к запуску, сомневается Половетс.

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Намного легче разговаривать с инвестором, если он понимает, что делает ваша компания. Как основателю компании, вам придётся тысячи раз рассказывать о ней. Чтобы быть эффективным, ваше представление должно быть ясным и кратким.

В этой статье я свёл процесс создания представления к ответам на семь вопросов. Если вы сможете ответить кратко на все семь, то хорошо справитесь с задачей представления компании.

Дорога длинна и трудна, но интересна и полезна!

Статья задумывалась как практическое руководство для желающих стать профессиональным веб-разработчиком. Я уже более 20 лет пишу код для веба. Я ежедневно работаю с веб-разработчиками и помогаю им. В статье я опишу, что вам нужно выучить, когда вам нужно это выучить и где взять информацию (чаще всего даже бесплатно). Затем я дам совет по получению реального опыта, и что самое важное – по получению денег за написание кода.

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

Что нужно помнить:

1. Статью разрешается пролистывать

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

Начните с начала, и продолжайте, пока не дойдёте до конца; и там уже остановитесь.

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

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

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

Изображение с сайта projectimo.ru

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

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

А риск того, что проект неожиданно покинут ключевые разработчики, вообще приводит в ужас многих риск-менеджеров.

Общение с очередным респондентом. Кадр из к/ф Матрица (The Matrix, 1999)

Как вы знаете из наших прошлых постов, в Mail.Ru Group есть своя UX-лаборатория, которой более четырех лет. Сейчас в большинстве крупных IT-компаний либо уже есть направление UX-исследований, либо планируется его запуск. Наша лаборатория работает только с продуктами Mail.Ru Group, но мы решили сделать исключение и приоткрыли её двери для внешних компаний и проектов, знающих о ценностях UX-исследований, но пока не решившихся выделить бюджет на их проведение.

Для выбора внешнего «заказчика» мы распространили информацию о нашем конкурсном проекте в социальных сетях и устроили розыгрыш бесплатного юзабилити-тестирования. Победителем стала команда проекта service-centers.ru — это сайт для поиска и выбора сервисных центров по всей России.

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

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

Для начала я должен немного подробнее рассказать о Badoo, чтобы вы понимали, кто работает с нашим API и почему оно так часто меняется.

React, Redux, Angular, JavaScript, Dart — мир фронтенда находится на грани полномасштабной войны адептов разных технологий. Настало время героев — кто спасёт мир в веб-разработке и станет главным героем новой эпохи?

Кажется, об этом знает фронтенд-тимлид компании Wrike Евгений Гусев. Нам удалось отвлечь его от работы и задать несколько вопросов, которые так волнуют тех, кто уже успел попробовать Angular 2 или ещё только слышал о нём. Евгений рассказал нам о  преимуществах Angular 2, скорости развития проекта, трудностях и радостях перехода на него. Мы успели обсудить React, JavaScript и Dart, — в общем, сравнить и изменить все силы. Впрочем, хватит тизеров. Магистр, вам слово!



— Расскажите о себе, о том, с чем работаете и как попали в Wrike?

Меня зовут Евгений, и я пишу на Dart и Angular 2. Наверное, странное начало, но надо расставить все точки над «i». Работаю фронтенд-тимлидом в компании Wrike, а начинал с С++ под микроконтроллеры, писал немного на том и на этом, потом дошёл до C#. Когда перешёл в Dell, начал плотнее общаться с фронтендом, причём самым банальным образом: кому-то нужно было писать UI, а никого не было. Причём писать начал сразу на CoffeeScript (да-да!). Годы шли, и я перешёл в компанию, в которой я сейчас и работаю, а именно Wrike. Мы разрабатываем крупную SaaS-платформу для управления задачами и совместной работы. Сейчас у нас почти 30 фронтенд-девелоперов, плюс команда верстальщиков, и мы, как Алиса из небезызвестной сказки, всё растём и растём.

Wrike прошёл довольно большой путь: от совсем небольшого стартапа до двух миллионов строчек кода за 9+ лет разработки. Конечно, за это время у нас сменилась куча фреймворков и технологий. Всё начиналось с Dojo, потом Ext.js. Мы писали на Polymer 0.5, и, когда он стал deprecated (с выходом версии 1.0), перед нами встал вопрос — что же выбрать? Собственно о том, какие у нас были варианты, и почему мы в итоге выбрали Angular 2, я и расскажу в своём докладе.

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

Как сделать сайт, который понравится пользователю? Какой он должен быть: красивый, с удобной навигацией, с запоминающимся URL? Прежде всего, сайт не должен тормозить — у пользователя должно складываться впечатление, что всё летает. Это первично. Всё остальное решается по мере разработки. О том, как воспринимают сайт пользователи, от чего это зависит и когда производительность решает, мы поговорили с Денисом Мишуновым, frontend-разработчиком (в прошлом контрибьютор в CMS Plone в составе Plone UI Team), автором статей про производительность в Smashing Magazine и активным спикером на профессиональных конференциях (среди которых From The Front, JSConf EU, JSConf Budapest, Smashing Conference, а теперь и HolyJS)



— Расскажи о себе. Какой был путь к web-разработке, почему именно она? Чем ты сейчас занимаешься?

— До того, что сейчас называют веб-разработкой, я дошёл быстро, уверенно и предсказуемо: первый компьютер, первый, никому не нужный, сайт, осознание бренности бытия. Дальше было чтение первых страниц «Программирование на Perl» Ларри Уилла и Тома Кристиансен с депрессивным верблюдом на обложке, повторное осознание бренности бытия и, как следствие, откладывание верблюдокниги. А потом я открыл для себя «Designing with Web Standards» Джеффри Зельдмана. Потом было, конечно же, «Ководство» Лебедева и много всего остального. Но книга Зельдмана была переломной. Хотелось бы сказать что-то красивое типа: «мир веба захватил меня после прочтения», но на самом деле я просто понял, что по сравнению с «конструктор электронных аппаратов» (которых из нас тщетно пытались сделать в институте), интернет-разработчик, а именно так это называлось в начале нулевых, звучит откровенно круче.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

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

Для быстрого роста интернет-компаниям надо тестировать гипотезы. Чтобы систематезировать эксперименты и связать действия команды с аналитическими данными можно использовать hopox. Однако, он сам не придумает гипотезы.

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

Всем привет!
Мы давно не писали на Хабр (который уже не тот), но в конце прошлого года выпустили новую версию Wiren Board — контроллера для автоматизации с открытым ПО, и сегодня расскажем о ней (под катом есть скидка!)

Введение в MVP, MVC, MVVM и VIPER. Что между ними общего и в чем разница.

Делаете все по MVC, а получается некрасиво? Сомневаетесь, переходить ли на MVVM? Слышали о VIPER, но не уверены, стоит ли оно того?

В этой статье я кратко рассмотрю некоторые популярные архитектурные паттерны в среде iOS и сравню их в теории и на практике. Больше информации вы найдете при переходе по ссылкам, указанным в тексте.

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

Разберем процесс, как это обычно происходит. Аналитик получает запрос на изменение функционала в виде тикета из техподдержки, технического задания или прямой жалобы клиента. Суть запроса в том, что что-то там в системе плохо и нужно подумать, как это исправить. Или что нужно сделать вот тут на этом экране еще одну такую возможность. Или нужно, чтобы «у пользователя была возможность сделать вот это». Часто аналитик просто записывает требование в том виде как оно пришло: в виде нескольких предложений или user story, формирует из этого задачу на изменение (или несколько задач) и отправляет её разработчику. Далее происходит то, что описано в последнем предложении предыдущего абзаца. Разберемся почему.

Jade — это препроцессор HTML и шаблонизатор, который был написан на JavaScript для Node.js. Проще говоря, Jade — это именно то средство, которое предоставляет вам возможность написания разметки совершенно по новому, с целым рядом преимуществ по сравнению с обычным HTML.

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

Мобильный трафик растёт и занимает, в среднем, уже около 25% от всех посещений. Если раньше потеря этих посетителей была незначительной, то сейчас это каждый 4 или 5 пользователь. Думаю, статистику приводить не надо. Мы плотно и серьезно занялись разработкой новой мобильной версии виджета. Собрали весь опыт предыдущих ошибок и неделями тестировали результаты. Повторюсь, что мы разрабатывали мобильный виджет, а не улучшали собственный сайт. В результате собрали список самых смертельных ошибок в мобильной версии сайта. Прошлись по ошибкам мобильного дизайна и мобильной верстки. Все эти ошибки убивают конверсию мобильного трафика. И самое время обратить на это внимание:

1. Слишком длинные формы захвата.

Это настоящий убийца конверсии на любом сайте! Особенно к этому чувствительны мобильные версии, так как заполнять анкеты на телефоне, крайне, не удобно. Избавляйтесь от них.
На примере видно, насколько грамотно поступили ребята из Тинькоф банка, которые разбили длинную заявку «на кредит» на шаги. Заполнив всего 4 поля, посетитель станет лидом и, если он отвалится на втором шаге, то контакты его останутся.