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

Так было раньше и это работало. Я сам прибегал к таким хитростям неоднократно. Однако, мир вокруг стремительно меняется. Современный продукт настолько сложен, что одна картинка не даст понимания и ответов на вопрос “Как это работает?”. Схематичное или wireframe прототипирование тоже постепенно угасает в закате, так как черно-белые линии и прямоугольники не дают клиенту полного понимания. Всё больше желающих сегодня видеть живой прототип, а не серию картинок…

Agile — это мода, тренд, слово, которое мелькает везде и повсюду (уступая, кажется, только коучингу).

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

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

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

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

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

p.s. космические таланты: как Королев и Гагарин :) ну и Валентина Терешкова! с праздником, поехали!

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

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

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

Ты дитя пайчарта или дата-сайентолог? Простой (нет) тест из 15 вопросов на знание мобильной аналитики от AppMetrica покажет.

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



Все, набравшие достаточное количество ответов для звания «дата-сайентолога», получат скидку при покупке билета на Международную мобильную конференцию MBLT17, которая состоится 25 апреля в Москве. Делитесь своими результатами на Facebook, приходите на MBLT17 и забирайте классные подарки на стенде AppMetrica.

Дерзайте ;)

Интерес к CRM-системам непрерывно растёт, они решают проблемы загрузки ресурсов и эффективности работы бизнеса. Именно поэтому этот класс программного обеспечения заслуживает пристального внимания не только с позиций функциональности и практики, но и с позиций истории. Мы взялись за эту работу и написали небольшую историю CRM. Из статьи вы узнаете:

• кто был крёстным отцом CRM-систем
  
• как проектировать софт на салфетке без UML-диаграмм
  
• как работала механическая CRM
  
• сколько млрд. $ заплатил Oracle за свою недальновидность.
  

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


Caricatura.ru

Написано в сотрудничестве с Ревазом Бухрадзе (редактор: Ангелина Кипелова)

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

«Вся жизнь — управление рисками, а не исключение рисков» Уолтер Ристон

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

Управление рисками – это не просто теоретическая и отвлеченная тема корпоративных митингов, не просто условная абстракция из мира менеджмента. При правильном применении управление рисками – это инструмент принятия решений. Этим инструментом часто и незаслуженно пренебрегают, принимая решения на основе интуиции или других факторов. Оценка рисков зачастую сводится к тому, что «да что там обсуждать, риски минимальны» или наоборот: хорошие идеи отвергаются из-за больших рисков. Но что это значит на практике? Какой риск считать большим или маленьким? Что вообще делать с этими самыми рисками?

Разработчик Дмитрий Лукьяненко, чью лекцию мы публикуем сегодня, не только является специалистом Яндекса, но и умеет проверять на прочность решения разработчиков других компаний. Это позволяет учиться на чужих ошибках — не исключая порой своих, конечно. В докладе Дмитрий поделится примерами Android-уязвимостей, в том числе найденных им собственноручно. Каждый пример сопровождается рекомендациями — как нужно и как не нужно писать приложения под Android.



Меня зовут Дмитрий, я работаю в компании Яндекс в минском офисе, занимаюсь разработкой аккаунт-менеджера. Это библиотека, которая отвечает за авторизацию пользователей. Поэтому мы поговорим о безопасности Android-приложений.

Итак, в данной статье речь пойдет о том, как найти себе native speaker для практики разговорной речи бесплатно.



Расскажу небольшую предысторию: год назад, передо мной встал вопрос о том, как найти кого-нибудь для практики разговорной речи. Я проанализировала много вариантов, таких как, обмен языком с жаждущими выучить Русский язык (сразу скажу, таких желающих очень мало), найм репетитора(минус в том, что он как правило не native speaker), поход на курсы(минус группового обучения), различные сервисы, предлагающие уроки с нативами(довольно дорого в пересчете фунты/доллары на рубли),… Но! У всех этих вариантов есть один САМЫЙ большой недостаток — они платные, а цель стояла подтянуть разговорную речь абсолютно бесплатно.

Принято считать, что разработчики смартфонов и прочей мобильной электроники (планшетов, ноутбуков, смарт-часов и пр.) наживаются на бедных потребителях. Видели новости с заголовком вроде «айфон нам продают за 500 баксов, а цена его комплектующих всего 250»? Я как раз об этом. Однако Apple со своими смартфонами – это ещё относительно честный производитель, который делает минимальную наценку. Неужели бывает хуже? Бывает. Пальму первенства в области развода покупателей удерживают – тарам-пам-там – производители наушников!

Всё дело в том, что производство наушников – бизнес крайне высокомаржинальный. Если не считать профессиональные аудиофильские модели ценой в пару тысяч долларов, где действительно применяются уникальные компоненты (вроде моделей STAX или Astell&Kern), подход к созданию «ушей» у всех производителей примерно такой. Берём старую начинку, слегка подкручиваем звучание (ну чтобы новая модель хотя бы немного отличалась от старой), чуток изменяем дизайн (с той же целью), продаём. Всё! Учитывая, что каких-либо реально дорогостоящих компонентов в массовых серийно выпускающихся наушниках нет, а на разработку «c нуля» тратиться не приходится, стоимость производства (cost of materials) одного флагманского экземпляра практически любого бренда редко превышает 50, ну максимум 70 долларов. Откуда же появляются модели за 500 баксов и дороже? Оттуда и появляются – потребителю впаривают не столько технологии и звучание, сколько бренд. Давайте-ка разберёмся в ситуации поглубже и параллельно обозреем линейку «антипафосных» наушников не так давно появившегося на российском рынке бренда Bluedio. Наушники этого производителя ориентированы как раз на тех, кто не желает выбрасывать даже лишний рубль (пусть даже может себе это позволить) и при этом хочет получить реально клёвые, хорошо звучащие «уши». Без наценки за «пафос».

---

Самое простое определение успеха: постановка, стремление и достижение цели.

---

Доля людей, успешно добивающихся задуманного — менее 10%. Только 8% новогодних обещаний выполняются.

Продажа продуктов по самореализации и мотивации — многомиллиардный рынок. Эти семинары и тренинги помогают достигать миллионную прибыль своим авторам, но не помогают добиваться целей. К успеху приходят все те же 10%.

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

Главный ключ к успеху — человек, который его достигает

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

Основное отличие тех 10% победителей не в генах или воспитании: они не сходят с пути, работают над достижением цели и не опускают руки, если что-то не получается. Они действуют.

Действие — неотъемлемая часть успеха

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

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

Содержимое статьи:

• Как бесплатно получить «вечную» Premium-подписку
• Где располагается статистика и насколько хорошо она работает
• Все ли конструкции из знаменитого учебника English Grammar in Use воспринимаются как правильные
• Хороша ли интеграция с браузером, MS Word и Google Docs
• Где разработчики перестарались

Очень много недопонимания в среде дизайнеров и разработчиков. Также много глупых вопросов, связанных с UX и UI у новичков. Часто просто из-за того, что люди не знают сути понятия UX/UI и, не зная о чем говорят, называют вещи не своими именами.

Я хочу раз и навсегда поставить точку и простым понятным языком объяснить, что значит «UX/UI дизайн».


_{Разные типы интерфейсов для заточки лезвий.}

Представляю очередной перевод статьи. Сегодня это короткая рекламная статья из блога компании Optanix. «Why You Need to Manage Services, Not Just Infrastructure», автор: Kishore Ramamurthy.

Зачем Вам тратить свое время на очередную рекламу? Не спешите делать выводы. На мой взгляд, статья интересна, т.к. дает доходчивый пример описания ценности сервисного подхода к управлению ИТ. Ее можно брать как шаблон для обоснования полезности CMDB и сервисно-ресурсных моделей своему руководству, как от ИТ, так не от ИТ.

Интересно? Прошу под кат. Не согласны? Прошу оставлять комментарии. Не только не согласны, но и хотите понизить рейтинг публикации? Тем более прошу оставлять комментарии.

Здесь и далее курсивом, комментарии переводчика.

Представляю перевод статьи Стюарта Рейнса «Прошлое и будущее Управления ИТ Услугами» («The Past and Future of IT Service Management» by Stuart Rance), опубликованную в блоге ITSM.Tools.

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

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

Хочу поделиться историей, ну и заодно услышать мнения других участников хабрасообщества. Это небольшая история о том, как агрессивное внедрение методологии разработки Agile (Scrum) в отдельно взятой российской IT компании послужило началом исхода из компании лучших разработчиков. Обычно в статьях про Agile рассказывают, какая это классная и полезная методология, и вообще — это лучшее, что было придумано в этом направлении. Возможно, эта статья поможет взглянуть на Agile с другой стороны, ведь у любой монеты, как оказалось, есть две стороны.

В общем, в 2010-м году была основана одна российская компания (что-за компания конкретизировать смысла нет), работала она в сфере IT-разработки (ПО для банковских продуктов).

Представьте, что у вас есть корпоративная информационная система в развитие которой вкладывается 200+ млн. рублей ежегодно. С момента внедрения документация на систему превратилась из одного Технического задания на 600 страниц в 300 Технических заданий, у каждого из которых есть дополнение в количестве от 1 до 10 штук, и теперь она занимает объем 3 офисных шкафов и это ещё не конец… Фабрика по производству ПО исправно и ритмично (с периодичностью в месяц) выпускает обновление системы и документирует изменения.



Ребята, которые разрабатывали 34-й ГОСТ явно не рассчитывали на то, что дело может принять такой оборот. Да и книги по гибким методологиям разработки тоже не дают каких-то рекомендаций как с этим быть.

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

• Как в этом объеме документов найти те, что описывают работу определенного функционала системы?
• Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?
• Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?