Статья “Как обсуждать деньги с руководством или почему иногда останавливаются карьеры?” неожиданно набрала +165 и под 100 тысяч просмотров, и мы решили продолжить переговорно-зарплатную тематику.

Сегодня публикуем статью нашего коллеги Дмитрия Коткина, уже полюбившегося хабровчанам по теме противостояния давлению в переговорах.

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

Дмитрий Коткин “Переговоры о зарплате. Практические рекомендации.”

Одной из самых важных вещей в GTD является сила воли. Без нее вы не будет доводить дела до завершения, любая выбранная вами система не буде работать. Первый же приступ лени не даст вам заглянуть в список дел. GTD, todo list, канбан доска — это всё инструменты. Мы про них много читаем, учимся их использовать, даже программируем. Только самый важный инструмент, который всегда при нас, это сила воли.

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

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

Буду признателен за конструктивные замечания и предложения по опечаткам, переводу и/или оформлению. Приятного чтения!

Не так давно мы проводили опрос по проблемам в проектах для нашей новой программы “Формула управления проектами”. Получили более 600 ответов, которые распределились в темы работы с заказчиком, оценок работ, сроков, коммуникаций и прочих безусловно нужных проектных вещей.

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

Мы пригласили в студию нашего эксперта по управлению проектами Ивана Селиховкина (selikhovkin) и попросили поделиться историей наведения порядка. В итоге Иван рассказал историю о том, как он с коллегами по шагам за 90 дней привел компанию от хаоса к работающему проектному офису. Находясь при этом не на должности ТОП-менеджера. Все изменения шли СНИЗУ.



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

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

P.S. Если поможете нам с опросом по проблемам проектов — будем отдельно благодарны.

P.P.S. Краткое содержание истории по шагам — под катом:

За последние десять лет через меня прошло много начинающих разработчиков. Да и чего греха таить, я тоже когда-то был начинающим разработчиком. За это время я получил тысячи вопросов а-ля “как стать разработчиком”, а также просьб взять людей к себе на практику. К сожалению, даже под чутким руководством более опытных специалистов, далеко не каждому хватает сил и мотивации перейти на качественно новый уровень. Статистика — вещь упрямая: количество “пытающихся” и “достигающих успеха” распределяется согласно принципу Парето, т.е. 20/80, где из десяти человек максимум двоим удается пройти первоначальное испытание. Остальные отваливаются по дороге или процесс обучения у них растягивается на долгие годы. И все же, каким должен быть начинающих разработчик, какими навыками и знаниями он должен обладать? Об этом и пойдет речь в статье.

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

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

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

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


Иллюстрация Стивена Резига

Внезапное отключение российских банков от международных платёжных систем свалилось неожиданнее снега в декабре. Неожиданно выяснилось, что использование платёжных системах вероятного противника может вызывать побочные эффекты вроде валютного запора или дистанционного разрушения банков. Знаете, есть такая фобия — Гимнофобия, что означает “боязнь оказаться голым на публике”. Судя по всему, наше правительство ею не страдает (что могло бы радовать, но — нет). В итоге, все мы оказались именно в таком положении.

Из этого положения есть разумный выход — переключится на Национальную Платёжную Систему вместо вражеских visa/mastercard. Но её не существует даже в виде проекта. Существует лишь законодательная инициатива и смутные желания, этой самой инициативой вызванные. И поэтому огромное количество людей в костюмах сейчас нервничают и требуют начать её немедленную разработку. Собираются заседания, куда вдруг приглашают не только людей в клетчатых рубашках, но даже одного-двух избранных в растянутых свитерах. Приказывают начать разработку прямо сейчас. Ну, или понедельника. Ладно, в этот не успели — начните со следующего. А ещё лучше начать сразу внедрение какой-нибудь системы и одновременно вести её разработку. Как бы не вышло так, что на гос.тендере заказ получит какая-то no-name компания, которая возьмёт, скажем, Кибер-плат, перекрасит, назовёт SUPERVISA, а потом стране с этим жить.

“Кто будет её проектировать и какие задачи каких пользователей она будет решать?” — это на порядок более важный вопрос, чем кажется. Если её будут разрабатывать люди из банковской сферы — то она будет нацелена на создание удобства банкам, а для людей и бизнеса — уж как получится (привет, Сбербанк!). Если её будут делать люди из онлайн-систем, то она в первую очередь будет решать задачи онлайн-бизнеса (банковские задачи им интересны в последнюю очередь). Если её будут делать бухгалтера, то это будет облачная 1С. Если её будут делать Erlang-программисты, то задачей будет показать его преимущества, перед другими унылыми языками. Если её будут делать любители короткошерстных терьеров, то… нет, не хочу даже искать ответ на этот вопрос.

Существуют три вида лжи: ложь, наглая ложь и статистика (источник)

Есть такой замечательный жанр — "вредные советы", в котором детям дают советы, а дети, как известно, всё делают наоборот и получается всё как раз правильно. Может быть и со всем остальным так получится?

Статистика, инфографика, big data, анализ данных и data science — этим сейчас кто только не занят. Все знают как правильно всем этим заниматься, осталось только кому-то написать как НЕ нужно этого делать. В данной статье мы именно этим и займемся.


Hazen Robert "Curve fitting". 1978, Science.

Структура статьи:

1. Введение
2. Предвзятая выборка (Sampling bias)
3. Правильно выбираем среднее (Well-chosen average)
4. И еще 10 неудачных экспериментов, про которые мы не написали
5. Играем со шкалой
6. Выбираем 100%
7. Скрываем нужные числа
8. Визуальная метафора
9. Пример качественной визуализации
10. Заключение и дальнейшее чтение

Возможно, вам уже попадался на глаза этот приём. Это поле ввода, которое выглядит так, как будто в нем есть текстовая подсказка (placeholder), но при начале набора текста она не исчезает, а отодвигается в сторону. Мне нравится эта идея. Брэд Фрост написал очень хорошую статью об этом приёме, подробно рассмотрев все «за» и «против».

Большинство примеров использования этой техники полагаются на JavaScript. В один прекрасный день я зашёл на nest.com, увидел там этот приём и задумался: а нельзя ли реализовать то же самое без JavaScript? И вот что из этого вышло.

Вот так выглядит форма на nest.com:

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

Добрый день, уважаемые коллеги. В этой статье я бы хотел рассказать о своем аналитическом понимании различий паттернов MVC, MVP и MVVM. Написать эту статью меня побудило желание разобраться в современных подходах при разработке крупного программного обеспечения и соответствующих архитектурных особенностях. На текущем этапе своей карьерной лестницы я не являюсь непосредственным разработчиком, поэтому статья может содержать ошибки, неточности и недопонимание. Заинтригованы, как аналитики видят, что делают программисты и архитекторы? Тогда добро пожаловать под кат.

В реальной жизни мы повсюду сталкиваемся с различными контрактами: при устройстве на работу, при выполнении работ, при подписании взаимных соглашений и многими другими. Юридическая сила контрактов гарантирует нам защиту интересов и не допускает их нарушения без последствий, что дает нам уверенность в том, что те пункты, которые описаны в контракте — будут выполнены. Эта уверенность помогает нам планировать время, планировать расходы, а также планировать необходимые ресурсы. А что если и программный код будет описываться контрактами? Интересно? Тогда добро пожаловать под кат!

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

Итак, почему же дедлайн близится, а решения всё нет?

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

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

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

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

О чем это все

Это будет короткий пост. Сначала личная история, а потом как это применить на практике к управлению сотрудниками.
Чисто опыт, никаких теорий.

Во-первых, часто говорят о работе на результате. О людях, ориентированных на процесс или на результат. Соотношение, как говорят, 95% к пяти. Рекомендую всем менеджерам проектов для начала великолепное видео Сергея Котырева в тему. Кстати, горячо рекомендую и другие видео посмотреть — Сергей достиг успеха на непростом рынке и знает, о чем говорит.



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

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

Уверен, многих технарей посещала идея создания своего бизнеса. Вот и у нас в определенный момент все звёзды сложились так, что казалось — это беспроигрышный вариант: сильная техническая команда, откуда ни возьмись появились менеджеры, готовые продавать наши услуги, есть даже пара проектов на старт. Грех не попробовать. И мы рискнули. Фактически всё надо ставить с нуля.

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



Итак, как известно, мозг — важнейший орган нашего тела. Кто-то говорит, что он — самая сложная вещь во вселенной. И незнание некоторых его особенностей может очень плачевно сказать на жизни человека.

Но обо всем по порядку.

Понимание роли мозга

Нет невежества страшнее, чем невежество по отношению к самому себе.

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

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

Я отошел от своего выгорания только недавно — несмотря на то, что случилось оно несколько лет назад. Да, мне было непросто… очень непросто. Когда я думаю о произошедшем, на ум приходит немало причин тому, что случилось со мной — но самое интересное заключается в том, что каждой из них я никогда раньше не придавал значения. Хотите повторить мой путь и выгореть? Пожалуйста, у меня готов целый список, как следует поступать в таком случае:

1. Думать о проекте и только о нем

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

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

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