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

К нам в Alconost часто приходят клиенты и говорят “Мне нужна справочная система для моей программы. Сделайте мне ПэДээФку”. Мы создаем руководство пользователя, оформляем PDF, а потом оказывается, что на самом деле нужна была контекстная справка с индексом и поиском.

Именно поэтому хотелось бы поделиться со всеми простыми схемами и описанием видов и форматов справки.

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

Люди задают мне и друг другу вопрос: что читать тестировщику? Как подтянуть свои знания до уровня своего опыта? Мой ответ — читать надо как можно больше. Но, как и в любой деятельности, рациональность не повредит. Можно ли прочитать немного меньше, но получить пользы больше? Мой ответ — это можно сделать с помощью сертификации ISTQB. Подготовка к экзамену даст хороший обзор знаний, которые могут пригодиться тестировщику. Сдав экзамен, вы получите документальное подтверждение знаний.

Давайте посмотрим, каким образом ISTQB-сертификация может быть полезна вам как тестировщику.

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

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

Велосипед

Итак, Вася долго трудился рядовым программистом, ведущим программистом и наконец стал Руководителем. У него есть команда отчаянных головорезов разработчиков в количестве двух единиц. Безусловно талантливых и знающих свое дело специалистов.

Вася получает первый заказ — надо сделать … велосипед.

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

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

Здесь не затронуты непосредственно «бизнес-вопросы»: способы поиска заказчиков, работы с ними, ценообразование и тому подобное. Акцент – на то, как организовать свою работу дома, побороть лень и не потерять при этом физическое и душевное здоровье.

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN'ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

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

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

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

Когда я говорил вкладывать деньги в обучение специалистов, вы продолжали раздавать деньги за рекомендации. Теперь у нас никто не работает, а все рекомендуют.

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

Совсем недавно мы отрелизили на hh.ru зарплатные кластеры, которые помогают оценить свою стоимость как специалиста. Это достаточно интересная и гибкая фича, такая, что с ее помощью даже можно провести небольшое исследование рынка труда, определив своё место в нем:

Тема изучения иностранных языков уже много раз обсуждалась здесь. В архивах можно найти много различных интересных способов и практических советов по поводу изучения языков. В какой-то момент я решил, что мне тоже, наверное, стоит поделится опытом, накопленным в процессе изучения иностранных языков: более-менее бегло я могу говорить на шести языках.
Всё, о чём я пишу здесь — это моё личное понимание проблемы изучения языков и моё видение возможных решений. Я не претендую на какую-либо истину или научность и не имею законченного профессионального образования в области лингвистики.
Я не буду рассматривать здесь изучение языка на уровне туриста, где достаточным уровнем является способность понять основные пункты меню в ресторане, сделать заказ или суметь спросить дорогу и понять, что тебе ответили. Знание языка на таком уровне, конечно, полезно, но это нельзя назвать «владением языком». Для меня уровень владения начинается с того момента, когда я могу спокойно читать тексты на этом языке используя лишь словарик, встроенный в электронную читалку (раньше AlReader, потом СoolReader, сейчас наконец PocketBook Reader).

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

Статья написана после прочтения статьи Копи деньги смолоду или пара утверждений, легко проверяемых в Excel.

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

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

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

(прим. перев. Перевод немного вольный, но я попытался максимально точно сохранить смысл текста, в то же время отыгравшись на некоторых некритичных моментах, просьба не судить строго :)
Должен также отметить, что я не по всем пунктам согласен с автором (в конце он уже начинает зарываться) и, разумеется, обзоры кода — это не серебряная пуля, но, тем не менее, очень и очень полезная практика.)

Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.

Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.

Для написания этой заметки  было затрачено:

• 68338 километров на поездки.
• 72 человеко-часа на почтовую переписку.
• 423 человеко-часа на эксперименты с коллективом в 30 человек.
• 88 часов на подготовку докладов и выступления на конференциях.
• 17 чашек кофе на беседу с мудрыми людьми на афтепати.
• Порядка 25 часов на набор этого текста и правку багов в нем :).
• До смерти замученный копирайтер, который был вынужден разбирать мои черновики, аудиозаписи и вообще ему спасибо.

Много денег и времени. Пожалуй, самым затратным (по нервам, времени и деньгам) был эксперимент над собственной командой, о котором мне безумно неловко вспоминать. Но об этом — ниже.

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

Смысл такого подхода: платить по справедливости. На сколько наработал — столько и получил. Это честно, это логично, это — прекрасно!

Ну, логично же, что:

• Продажникам  нужно назначать процент с оборота. Волки должны быть голодными. (Да, есть альтернативное мнение, что применить такой подход — значит «обложить себя дополнительным налогом». Но как по мне — тут все справедливо :-)).
• Офисному планктону — ставить оклад. Стабильность для них — ооочень важное условие существования.

А вот с творческими единицами (дизайнерами, программистами) — все значительно сложнее.

Мы недавно провели опрос руководителей ведущих диджитал-агентств и веб-студий страны на тему «а как вы используете KPI по отношению к труду творческих единиц», в результате получили вот такую картинку:



Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.

В октябре я уже рассказывала о способах оценки тестирования, все страждующие и сочувствующие могут посмотреть запись здесь. А сегодня мне захотелось затронуть тему метрик проекта в целом, причём метрик не «длягалочных», а метрик «пользуприносящих» и «проектыулучшающих». Именно поэтому, вместо сухих формул и перечня метрик, я расскажу 3 истории из опыта о внедрении и использовании строго определённых метрик в строго определённых условиях — и о результатах, которые с их помощью удалось достичь.

Зачем что-либо измерять?

Есть проект. Ваш любимый, родной, которому вы желаете расти и процветать.
Но как вы оцените его процветание, если нет критериев этого самого процветания?
Как вы сможете оперативно среагировать на проблемы до того, как они стали неисправимыми, если не будете использовать «датчик грядущей Ж»?
Как вы поймёте, что именно следует улучшать, если вам неизвестен источник проблем?

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

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

А если не приходят, значит метрику можно смело выбросить ;)