Тема «Умный дом» уже у всех на слуху. Про неё говорят, в неё вкладывают, её развивают… По этой теме к таким гигантам как Siemens, General Electric и др. присоединились, казалось бы, не совсем профильные компании, такие как Microsoft, Google, Apple.

Единого стандарта по теме нет, равно как нет инструкции, мол, «делай так и вот так», поэтому теоретически построить свой умный дом может каждый и именно так, как ему захочется и потому эту тему я не смог пропустить и активно к ней подключился. Не скажу, что с умными домами я собаку съел… нет, скорее так, понадкусывал, но тем не менее, на основе свое опыта и своих наблюдений попробую выложить развёрнутый… ммм… How-To? Нет, не потянет. Обзор? Тоже не то… Скорее это будет напутствие или некий набор советов.

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

Самое главное — это то, что статья рассчитана на людей, которые толком ещё не поняли, нужен ли им вообще этот самый «Умный дом» и нужно ли влезать в эту тему?

Теперь термин.
Будем честны, «Умный дом» — это не только такая система с искусственным интеллектом, которая разговаривает с Вами по утрам в ванной (пока вы бреетесь) и готовит Вам ужин пока вы едете домой. Не нужно путать систему с женой.

Безусловно, все те кто общается с ОС Linux хоть раз да имели дело(во всяком случае слышали точно) с командной оболочкой BASH. Но BASH не только командная оболочка, это еще и превосходный скриптовый язык программирования.
Цель этой статьи — познакомить поближе юзеров с bash, рассказать про синтаксис, основные приемы и фишки языка, для того чтобы даже обычный пользователь смог быстренько написать простой скрипт для выполнения ежедневной(-недельной, -месячной) рутинной работы или, скажем, «на коленке» наваять скриптик для бэкапа директории.

Доработка типового программного обеспечения под требования заказчика — это обыденное дело, если оно правильно организовано. Однако часто можно встретить примеры, когда разработчики берутся выполнить работы без ТЗ (технического задания) по настоянию заказчика. Что происходит в итоге? Обе стороны загоняют себя в яму, которую выкопали сами. Разработчик не подозревает, что он будет вынужден выполнить объем работ во много раз больше предполагаемого, и рано или поздно остановит эти работы, нахлебавшись раздувшихся аппетитов заказчика, которые будут расти в геометрической прогрессии, не имея формальных ограничений. В такой ситуации разработчик рискует никогда не завершить работу, а заказчик — никогда не получить нужного результата. На ранних этапах развития компании мы в этой яме побывали неоднократно, поэтому представляем вторую часть наших историй о ТЗ — когда его нет.

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

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

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


Когда полез не с той стороны: соблюдайте технику безопасности при внедрении CRM-систем

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


А по техническому заданию был гоночный болид для Формулы 1

Синерги́я (греч. συνεργία — сотрудничество, содействие, помощь, соучастие, сообщничество; от греч. σύν — вместе, греч. ἔργον — дело, труд, работа, (воз)действие) — суммирующий эффект взаимодействия двух или более факторов, характеризующийся тем, что их действие существенно превосходит эффект каждого отдельного компонента в виде их простой суммы[1], эмерджентность.

Википедия.

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

Мне постоянно приходится сталкиваться с одними и теми же проблемами и решениями многие из которых приходится пояснять в каждом новом проекте заказчикам, некоторые – программистам. А потому я считаю, что о процессе интеграции стоит поговорить подробно. В большинстве примеров я выбрал различные случаи интеграции 1С и CRM, так как сегодня именно этот вопрос, как показывает моя практика, наиболее актуален. Хотя данная статья подойдет при интеграции практически любого программного обеспечения. Итак начнем.

Труд — это отец удовольствия.

Стендаль.

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

Внедрение программного продукта с точки зрения бизнес-консультанта.

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

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

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

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

О том, как вести проект внедрения ERP-системы от и до, я также постараюсь рассказать в следующих статьях. А сейчас я хочу поговорить о самом важном – начале внедрения.

«Чтение научной статьи – то, что заставит вас чувствовать себя глупее некуда», – пишет ученый Адам Рубин (Adam Ruben) в своей юмористической колонке для журнала Science. Адам прав: читая статью из рецензируемого научного журнала, многие из нас начинают с оптимизма («В конце концов это всего лишь несколько страниц»), а заканчивают отчаянным желанием срочно сменить сферу деятельности на такую, где научных статей или вовсе нет, или их пишут как-то иначе. На самом деле проблема не в статьях – а в том, как мы их выбираем и читаем.

О том, что советуют делать по этому поводу сами ученые, расскажем ниже.

Привет, Хабр!

Команда нашего образовательного проекта Хекслет состоит из людей, которые любят программирование. Еще бы! Любим так, что последовательно выпускаем практические курсы для начинающих программистов (и не только начинающих на самом деле), при этом мы по-настоящему дорожим этим ремеслом, поэтому не любим курсы в стиле «принт, а теперь цикл, а это называется класс, животное-собака, поздравляю, кодинг это легко, правда?», а начинаем свои «Основы программирования» с абстракции, чистых функций, рекурсии и структур данных. Хотя, конечно, курсы «стань программистом за 2 недели» позволили бы заработать получить больше денег.

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

Считается, что хороший программист страстно любит свою работу. В вакансиях наряду с «гуру», «суперстар» и «ниндзя» часто встречается «… who is passionate about programming...» в качестве требования к кандидату. Сказать, что ты не очень-то кайфуешь от кодинга, но доволен работой и зарплатой, и на вас как минимум посмотрят косо. Однако, есть большая разница между «не испытывать страсть» и «ненавидеть и не хотеть».

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

Я разработчик, но это не моя страсть

Я senior веб-разработчик в хьюстонском стартапе, и я должен вам кое в чём признаться. По моим наблюдениям, мало кто из разработчиков в таком признаётся.

Веб-разработка — не моя страсть.

С чем сейчас работает руководитель проекта? Какие инструменты использует, чтобы планировать, собирать данные, контролировать ситуацию, готовить отчеты?

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

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

• Asana
• Trello
• SmartSheet
• Мегаплан
• JIRA
• Clarizen

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

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

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

Кто заинтересовался — прошу под кат.

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

Так уж сложилось, что последние несколько лет я занимал самые разнообразные руководящие должности в полудюжине компаний, занимающихся разработкой программного обеспечения разного рода. Довелось побывать и тимлидом, и менеджером проекта, и группы проектов, руководителем отдела и руководителем технического направления; подопечных бывало от двух до ста пятидесяти человек, да и размеры компании варьировались от трёх до двухсот тысяч работников. Неизменным оставалось только одно: чисто управленческая работа, постепенный и окончательный отход от технических задач.

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

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

Честно говоря, написание этого текста преследовало вполне корыстные цели: он является некоторой лакмусовой бумажкой для отправки людям, с которыми предстоит сотрудничать.

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

Добрый день, уважаемые хаброжители!

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

Поиск выдал мне всего одну статью на Хабре по схожей тематике — «Талмуд по формулам в Google SpreadSheet». В ней дано хорошее описание базовых вещей для работы в excel (хотя он и не 100% про сам excel).

Таким образом, накопив определенный пул запросов/задач, появилась идея их типизировать и предложить возможные решения (пусть не все возможные, но быстро дающие результат).

Речь пойдет о решении наиболее распространенных задач, с которыми сталкиваются пользователи.

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

«У хорошего бухгалтера не сойтись может только юбка.»

Несколько лет назад передо мной встала задача вести учёт денежных расходов, чтобы в конце месяца понимать сколько и куда денег тратится.
Перебрав самые известные приложения (GnuCash, Kmymoney, aqbanking, grisbi, cbb, ledger мне по тем или иным причинами ни одно не понравилось. Кроме последнего.

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

Сергей, выпускник IMD Business School и, по совместительству, студент MBA Consult, дал интервью о том, как поступал и учился в бизнес-школе своей мечты.

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

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