23
Июл
2013

А почему бы не перестать страдать по мелочам?

А почему бы не перестать страдать по мелочам?

Вот ждёте вы важное письмо от коллеги. 5 минут, 10, 20 — а нет его! Блин, а проверю-ка я спам. И точно — есть, 19 минут назад пришло. Чёрт, я же вроде уже добавлял этого человека в whitelist — почему письмо в спаме? Надо разобраться, проверить правила… Но сейчас нет времени, это мелочь, письмо срочное, а в эти правила как закопаешься, так на полчаса, еще и админов может быть придётся дёргать. Нет, потом…
А завтра письмо от коллеги опять в спаме.

Так, заходим на сайт… Блин, не сохранилась авторизация. Вот на всех сайтах сохраняется, а тут нет. Почему? Может быть почистить куки? Может сохранился старый пароль? Надо разобраться… Нет, ну это сейчас и в настройках рыться, и не дай бог, сохранённые пароли для других сервисов потру, нет, потом. Это ведь, в сущности, мелочь, а мне надо работать…
А завтра снова раздражение от не сохранённой авторизации и минута на размышление о причинах.

О, вот библиотека, которая делает то, что мне надо. Хм, на Python, а мне надо на С++. А на С++ такой нет. Ну ок, почитаю питоновский код, пойму общую идею и перепишу на С++. Ух ты, у моего редактора нет подсветки кода на Python! Может быть есть какой-то плагин? Или поискать другие редакторы? Ай, ну ладно, это ведь одноразовая задача, не буду тратить время — сейчас полдня потрачу на сравнение десятка IDE и редакторов кода на Python, а у меня ведь задача совсем другая, плюну, это ведь мелочь…
А завтра к библиотеке на Python выходит обновление и его снова приходится читать.

Почему бы не перестать страдать по мелочам?
(далее…)

Метки:
Опубликовано в GTD

читать далее
23
Июл
2013

MVP – не дешевый продукт, а умный процесс познания

MVP – не дешевый продукт, а умный процесс познания Минимально жизнеспособный продукт (minimum viable product — MVP) – не всегда уменьшенная/удешевленная версия законченного продукта. Определение точки, в которой можно выпустить MVP, с самого старта может сэкономить вам много времени, денег и ваших слез.

Дроны в Хартленде

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

Опубликовано в mvp, steve blank, дроны, инвестиции, камера, команда, мжп, Переводы, Робототехника, стартап, стив бланк, Управление проектами

читать далее
23
Июл
2013

С гвоздем в глазу все видится гвоздем

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

Заполучив что-то вроде нового супермасштабируемого молотка, горячо обсуждаемого на Hacker News, вы лупите им по всему, что попадается на вашем пути, пока каждая ваша вещь не превратится в пыль, а все, кого вы любите, не скончаются от тяжелых черепно-мозговых травм.

Переведено в Alconost Translations.

С гвоздем в глазу все видится гвоздем

(далее…)

Опубликовано в alconost translations, Блог компании Alconost, Inc., локализация, новая технология, Переводы, стартап, Управление проектами

читать далее
23
Июл
2013

Создаем резюме на LaTeX — как и зачем?

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

(далее…)

Метки: ,
Опубликовано в cv, Human Resources, LaTeX, Разработка

читать далее
22
Июл
2013

Правило программиста #1: оставьте эмоции дома!

Как программисты, мы гордимся нашей работой. Мы показываем эту гордость, выполняя наши задачи лучшим образом. Мы относимся к ним со всей дотошностью, вплоть да названий переменных и методов. Мы всегда выбираем нужные классы для конкретной задачи, не смотря на то, что пользователю все равно, использовали ли мы List<KeyValuePair<Guid, string>> или Dictionary<Guid, string>. Мы нервно стараемся довести все до идеального состояния. Многие даже могут подумать, что у нас ОКР.

Но что происходит, когда разработчик слишком гордится тем, что он или она написали?

Что, если из-за этого эмоции проникают в код? Что может случиться, если программист не может расстаться не только с его или ее кодом, но и с методами ведения работы, принятия решений и своим поведением, как разработчика? (далее…)

Опубликовано в Human Resources, Программирование, Разработка, Управление проектами

читать далее
21
Июл
2013

Жизнь управленца, кадр 1, не надейтесь на понимание

95% своей сознательной жизни я связан с ИТ, начав как переводчик, достаточно быстро перешел в ИТ, развитие проектов, в общем кто плавал, тот поймет.

Основная проблема, с которой я столкнулся, во время своего путешествия, это конечно люди. Не плохие люди и не хорошие, а просто люди-сотрудники.

Так вот, в любой нормальной ИТ компании, которая занимается программерством, 90% это программисты процентов 7% технари, остальное административный отдел. Самые простые люди в компании это конечно администраторы, в прямом смысле этого слова, те люди кто делают чай, кофе, чистоту, учет и безопасность. И так часто происходит что именно эти люди самые бесправные, вы знаете что их легко заменить, их никто не замечает и тд и тп.
(далее…)

Метки: , , ,
Опубликовано в Human Resources, кадры, менеджмент, разработчики, Управление, Управление проектами

читать далее
19
Июл
2013

Стратегия продукта подразумевает ответ — «Нет!»

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

Стратегия продукта подразумевает ответ — «Нет!»

Как следует из последней рекламы Apple, могут существовать десятки тысяч версий вашего продукта, которые могут появляться из-за разных фич, важных и неважных. Большинство из этих версий с треском провалятся и только лучшие смогут обслужить рынок. (далее…)

Опубликовано в customer development, mvp, product management, startup, Переводы, продуктовая стратегия, разработка продукта, стартапы, стратегия развития, Управление проектами

читать далее
19
Июл
2013

Детальное описание действий IT-отдела — базовый набор документации

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

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

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

Метки: , , , , , , , ,
Опубликовано в аутсорсинг, базовые понятия, Блог компании КРОК, глоссарий, документация, каталог, Системное администрирование, список работ, стандарт, техподдержка, Управление проектами

читать далее
19
Июл
2013

Корпоративная утопия коммуникационной среды

imageРабота любой крупной компании ежедневно создает информационный поток в сотни, даже если не тысячи гигабайт информации, причем зачастую по большей части повторяющейся между собой. Мы храним цитаты доброй сотни ответов в переписке, включаем зубодробительные подписи с врезкой о конфиденциальности информации. Мы храним добрый десяток версий одних и тех же документов устраивая из «базы знаний» файловую помойку. Культура информационного хранения и обмена данных сродни бытовой культуре общества. Однако, если лучших из нас еще научили не сорить на улице, то очень немногие из лучших самостоятельно научились высоко-материальной культуре. Да-да, именно научились, учить-то нас, родившихся в обнимку с компьютером, было еще некому.
(далее…)

Метки: , , , , , , , , , , ,
Опубликовано в cmmi, Coworking: работа 2.0, google drive, GTD, iso 9000, pmo, SharePoint, skydrive, корпоративный портал, корпорация, управление документами, управление знаниями, управление командой, Управление проектами

читать далее
18
Июл
2013

8 вещей, которых не должен бояться разработчик

Изменять код
В процессе разработки программного обеспечения нет такого понятия, как «стагнация». Все, что вы разрабатываете сейчас — просто очередная версия компонента, который вероятно будет меняться в будущем. Изменение является самой распространенным явлением в мире разработки программного обеспечения и вам лучше принять это как факт. Рассчитывайте на возможные изменения всего, что вы разрабатываете и поэтому проектируйте ваш код более модульным. Это упрощает изменения и в тоже время увеличивает качество кода. Старайтесь придерживаться концепций DRY и YAGNI. Вы часто будете в ситуации, когда вы смотрите на ваш код и представляете, что вы могли бы сделать это лучше. Так пусть эта мысль не мешает вам спать. Садитесь сразу за дело и рефакторинг! Если не сделаете это сейчас, вы возможно никогда этого не сделаете. Чем дольше ждете, тем сложнее и дороже это будет. И это может вырасти в лишнюю головную боль, с которой не захочется связываться.
«Хороший код — это код, который легко изменять. Код стремится измениться до момента, когда его уже не легко изменять. Весь код становится плохим кодом». Неизвестный автор.
(далее…)

Опубликовано в GTD, качество кода, Программирование, Проектирование и рефакторинг

читать далее
1.102030.444445446.450460470.498