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

Хорошо кода есть точное тз. Например «сделать инструмент с длинным жалом и ручкой, позволяющий закручивать шурупы с продольной канавкой в 1,5 мм шириной при помощи руки»… ну или чтото такое. Берете и делаете отвертку.

Но когда у руля творческая личность, тз мутирует в чтото страшное.
Этап 1: «сделайте закручивалку»
Этап 2: «а вдруг головка у шурупа будет шестигранная»
Этап 3: «я подумал что пользователя заломает крутить самому»
и т.д.
В результате после 3х итераций мы получаем электрический шуруповерт. Это не плохо. Это замечательно. Электрошуруповерт гораздо удобнее отвертки (с тех пор как его купил, отверткой и не пользуюсь).
Но! Времени затрачено в 3 раза больше, потому что мы сначала сделали отвертку, потом выкинули жало и сделали сменные насадки, потом выкинули ручку и сделали рукоятку с электропитанием. В итоге от отвертки не осталось ничего. Грамотное тз нас бы спасло от делания начальной отвертки.

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

Вот такой у нас дрельдев!
А как у вас?

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

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

Office Groove 2007 — настольное приложение для синхронизации данных, совместной работы и удобного обмена файлами между пользователями и компьютерами без использования электронной почты и онлайн-сервисов. Подробно о программе рассказывает этот демонстрационный ролик.
Программа действительно чудесная, но, как большинство продуктов Microsoft, платная. Однако найдены сразу 2 способа, которые позволяют совершенно легально ей пользоваться с минимальными затратами.

С сайта www.trygroove.com можно скачать 60-дневную полнофункциональную демонстрационную версию, и в течение trial-периода настроить все необходимые рабочие области с любым количеством пользователей и компьютеров. Через 60 дней функциональность Groove станет ограниченной, в этом режиме нельзя будет создавать новые области и добавлять пользователей. Но при этом все существующие связи будут продолжать работать как ни в чем не бывало, поэтому обмен данными будет продолжаться в стандартном режиме.

Корпоративные клиенты тоже могут воспользоваться этой фичей и воспользоваться скидкой 99% при приобретении полноценной версии. По-моему, классное предложение! Хотя скидка почему-то не очень афишируется, так как об этом написано только на партнерском сайте Майкрософт: https://partner.microsoft.com/rus/salesmarketingsection/offerspromos/40088713

Необычный концепт представила креативный директор Лос-Анджеловского бюро Fair Enough Джулия Тсао(Julia Tsao). Это устройство представляет собой много маленьких экранов, способных перемещаться по разным поверхностям и взаимодействовать с предметами. Эти маленькие экраны могут работать как напоминания человеку, если он что-то забыл или потерял. Они смогут подсказать, на какое время у пользователя намечено собрание или напомнить о том, что нужно полить цветок.

Вольный перевод статьи Азы Раскина How To Critique An Interface.

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

Сложно ответить на эти вопросы в такой короткой статье, но я приведу хотя бы несколько советов:

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

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

Речь, какой мы её знаем, безусловно необходима, более того — она видится наилучшим на данном этапе развития средством обмена информацией между людьми. Лучше неё может быть только телепатический обмен мыслями, которым мы пока не владеем (хотя некоторые говорят, что уже не владеем). Однако с развитием IT, появлением компьютеров и интернета у нас появились гораздо большие возможности по организации нашего общения. Но мы по-прежнему продолжаем использовать старый добрый текст (как и я сейчас), либо речь (skype). Принципиально нового ничего не появилось, а если и появилось, то используется в каких-то отдельных организациях и обособленными группами людей, широкие же массы почему-то делают это по-старинке. Это проблема номер один.

Представляю вашему вниманию перевод статьи под названием "Better together; the practice of successful creative collaboration" от Stefan Klocek. Перевели специально для пользователей Хабрахабра с одобрением компании Cooper.

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



Двое (или больше) творческих людей могут использовать эти добродетели, если будут хорошо играть в команде. Практика “парного дизайна”, используемая в Cooper, взрослела больше чем десять лет, и развивается вместе с ростом компании, формируя новые пары, в которых дизайнеры учатся друг у друга каждый день. Хотя не существует никакой магической формулы, но большинство самых успешных совместных работ такого плана на нашей памяти обладали на удивление схожими характеристиками.

Любой приказ, который может быть неправильно понят, понимается неправильно (Армейская аксиома)

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

Наша программа настолько сурова, что даже логин отображается звездочками (bash.org.ru)

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

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

Уже догадались, о чем будет статья?

Третий год занимаюсь разработкой крупной системы на Java с использованием СУБД PostgreSQL. Система десктопная, клиент-серверная. Опытного Senior-Java-Developer-а у нас нет, поэтому приходится думать самим. Думать, строить, ломать, строить заново, опять ломать…
За время работы накопился некоторый опыт как по организации непосредственно работы с БД, так и по взаимоувязыванию этих платформ, о котором и хочу рассказать в этой статье.

Опишу выборочно некоторые вопросы, с которыми мы столкнулись при разработке и которые решили.

Около полугода назад мне в руки попала книга Чарли Пелерина How NASA builds teams. В книге описывались социальные проблемы крупных технологических проектов, которые стоили миллионов долларов космической промышленности США.

В книге Чарли я подчерпнула ряд идей об измерении социального контекста проекта. И провела некоторые наблюдения с командами гибкой разработки. Думаю, лучше всего систему NASA 4-D лучше применять для тематической командной ретроспективы.

Однако, независимо от используемого процесса и зрелости команды, описанные ниже 8-мь социальных параметров довольно интересно обсуждать. Разговор о них может дать ряд идей об усилении командного взаимодействия и социальных факторов успеха проекта.

По каждому из пунктов я описала базовое значение “максимума”. Читая описание социальных параметров, попробуйте задаться вопросом: “Насколько хорошо функционирует этот аспект социальной жизни нашей команды?”

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

Введение

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

КДПВ из google.images

Озарённый лучами вдохновения, хочу в данной статье наконец-то самморизировать опыт разработки интерфейса внутрикорпоративной CRM для компании Performance Lab. Особенность для меня лично в данном проекте была, прежде всего, в подходе к гайдлайнам — за основу была взята концепция Google Material Design.
Итак, если вы, как и я отдаёте предпочтение шрифту Roboto, сочным предустановленным цветовым палитрам, чётко сформулированным правилам поведения элементов… И, как и бОльшая часть, разработчиков вы банально предпочитаете Android, то добро пожаловать под кат. Впрочем, поклонникам iOS — тоже не запрещается :)

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