TL;DR. Многие стремятся к «тихому успеху» — делать работу, которая «говорит сама за себя». К сожалению, это неправильный ход в современном театре труда. Зачастую верно обратное — для офисного информационного сотрудника представление работы и есть работа. Да, внутренняя политика компании действительно несправедлива. Но посмотрим, как эффективнее сыграть свою роль в этом спектакле. Хотя статья содержит советы для консультантов, она даёт пищу для размышлений и работникам других профессий. По крайней мере, даёт возможность понять мотивы консультанта — прим. пер.

Недавно я прочитал книгу Кита Джонстона «Импровизация и театр». Восхитительная книга об импровизационном театре и, главное, как этому научить.

Книга вдохновила меня на несколько аналогий между импровизирующим актёром и консультантом, поэтому я написал серию из четырёх статей, вот первая из них:

Глава 1. Офис — это театр работы. В статье рассматривается центральная проблема — акт «представления» работы, перфоманса, и насколько он важен для современного интеллектуального труда, особенно для консультанта. Предлагается несколько идей о том, как думать на ходу, не скатившись в бред сивой кобылы (bullshit, BS).

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

Дальше я приведу несколько наборов слов, сгруппированных по типовым ошибкам. К каждому слову будет приложена транскрипция, приблизительная транскрипция на русском и ссылка на более детальную информацию в словаре. Так как большинство IT компаний все-таки работает с Северной Америкой, то транскрипции будут из US English.

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

Если вообще не соблюдать правила гигиены, быть токсичным, не последовательным, корыстным, обманывать других, то до первых денег вообще не добраться. Представим, что все хорошо, вы все молодцы и не за горами время, когда пойдет первая серьезная прибыль. Тут рушатся воздушные замки, которые были так скрупулезно выстроены каждым членом команды. Первый думал, что он главный и он заберет 80% прибыли, так как именно он продал машину и на его деньги жила первое время вся команда. Второй думал, что два основателя получат по 50%, так как он программист и создал то самое приложение, на котором все сейчас зарабатывают. Третий и четвертый думали, что они получат долю в бизнесе, как только пойдут деньги, ведь они работали почти круглосуточно и получали значительно меньше, чем могли бы в том же банке.

В итоге бизнес под угрозой развала. А ведь всего бы этого можно было бы избежать, правильно договорившись на берегу. Как?

ТЗ должно быть простым, понятным и проверяемым

Вы такое видели?

Каких только ТЗ я не встречал за 12 лет в этой теме. Классические пункты — это “бесшовный роуминг” и “устойчивое 100% покрытие всей площади”. Понятно, что все мы хотим прекрасной связи. Какими же словами описать то, что мы хотим, чтобы это можно было адекватно проверить?

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

Как в значке Wi-Fi три изогнутых линии, основных пунктов тоже будет три.



Тем, кто так или иначе связан с Enterprise Wi-Fi и не только, будет интересно.

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

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



Откуда он взялся? Из простой мысли, что иногда люди выходят из офиса поесть что-то снаружи. Ближайший магазин у нас в 10 минутах от офиса (с учётом спуска-подъёма). Гораздо дешевле и практичнее принести сотрудникам бесплатную еду, чем тратить их время на её поиски, пускай и не за счёт компании. Сначала это были только здоровые закуски, но потом по мере роста офиса стали появляться сосиски, а для тех, кто иногда остаётся ждать ночи перед релизом, — пицца. При этом горячая еда тут не хранится постоянно, а приезжает отдельно.

Давайте проанализируем, как такое решение вообще могло быть принято.

1. Научитесь гуглить
Быть программистом, — значит научиться искать ответы на свои вопросы. Научившись эффективно «гуглить», вы сэкономите много времени, затрачиваемого на разработку.

2. Не обещайте много, но делайте больше, чем обещали
Лучше сообщать вашей команде, что выполнение задачи займет три недели, но выполнять её за две, чем наоборот. Следуя этому принципу, вы выстроите доверительные отношения.

Всем привет!

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

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

Привет!

Меня зовут Рушан, и я автор Telegram‑канала Нейрон. Не забудьте поделиться с коллегами или просто с теми, кому интересны такие статьи.

Вкратце: пока не бросайте свой старый компьютер — используйте легкий дистрибутив Linux, чтобы возродить его!

Что вы делаете со своим старым компьютером? Тот, который когда-то имел хорошую аппаратную конфигурацию, но теперь считается устаревшим. Почему бы не восстановить его вместе с Linux? Я собираюсь перечислить лучшие легкие дистрибутивы Linux, которые вы можете использовать на своем старом ПК.

Лучшие легкие дистрибутивы Linux для старых ноутбуков и десктопов

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

10. Peppermint

Peppermint  —  это облачно-ориентированный дистрибутив Linux, не требующий мощного железа для запуска. Он основан на Lubuntu и использует окружение рабочего стола LXDE для более плавной работы.

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

Однажды задался вопросом — а как в целом в разных странах, ну и в первую очередь в России, защищаются от этой беды?

Про неконкуренцию

Вообще, уход сотрудника — это 3 «полярные лисички», а не одна.

Ушедший сотрудник:

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

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

О них и поговорим.

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

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

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

И еще, я показываю максимально простую реализацию кода. Я знаю про исключения, знаю про ORM, про предусмотренную защиту в фреймворках. Моя цель — показать наглядно, так, чтобы поняли все.

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