Опыт поиска работы на бирже Elance разгорелось горячее обсуждение темы способов конкуренции с индийцами и пакистанцами на площадках сайтов для фрилансеров. В продолжение этой темы публикую свой вольный перевод статьи Евгения Розинского о проблемах краудсортинга в Индии. По словам Евгения он имеет 15 летний опыт в этой области и знает о чём говорит. Это взгляд из США, со стороны работодателей. Статья была опубликована ещё в 2013 году, но проблемы которые в ней рассматриваются сегодня стали ещё более актуальными.
Индийский ИТ-аутсорсинг стал бизнесом, который поставлен на поток. Бизнесом без каких-либо инноваций Единственным сомнительным плюсом которого является дешевизна. Но не миф ли это?
Это не попытка написать научную статью или предсказать будущее. Это просто личное мнение, сложившиеся у меня на основе более чем 15 лет работы с различными поставшиками услуг в Индии и по всему миру. Не стоит рассматривать статью как попытку сформировать стереотип для каждого сотрудника страны с населением 1,2 миллиарда человек. На протяжении многих лет мне посчастливилось работать с блестящими индийскими инженерами и менеджерами, как в Индии, так и в США. Этой рецензией я пытаюсь описать индустрию аутсорсинга Индии в целом и отметить характерные проблемы с которыми мы сталкиваемся в качестве клиентов, а не людей, работающих там.
Мои выводы и предположения базируются на том, что многие компании переходят к более гибким стратегиям разработки, в которых процесс принятия решений и способность адаптироваться является ключевой.
Читать полностью »
Рубрика «управление рисками» - 3
Почему Индийский аутсортинг обречен
2015-03-29 в 19:53, admin, рубрики: аутсорсинг, Карьера в IT-индустрии, Программирование, управление людьми, управление проектами, управление рисками, фрилансУправление программными проектами: процессы, инструменты, методики
2015-03-23 в 8:42, admin, рубрики: управление временем, управление задачами, управление качеством, управление проектами, управление рискамиСуществуют разные представления о том, как ведётся творческая работа. Для многих людей творец – это личность (поэт, художник, изобретатель), которая создаёт своё творение в момент озарения. Управлять озарением? О, нет! Это невозможно!!!
Тем не менее, задача управления творчеством во все времена была актуальна. Инвесторам, менеджерам, государству хотелось бы иметь предсказуемость на счёт того, когда будет выпущен разрабатываемый творческий продукт (будь это книга, самолёт, компьютерная программа или кинофильм).
Творческая работа может вестись как индивидуально (одним творцом – учёным, художником, композитором или поэтом), так и коллективно (когда над созданием произведения работают коллективы людей разных специальностей). В данной статье мне бы хотелось сконцентрироваться на вопросах управления творческими коллективами на примере распределённого коллектива программистов, художников и дизайнеров из трёх стран, который выпускает приложение, продаваемое во всём мире. Каждый год продаётся более 10 миллионов экземпляров. Годовая выручка – 1 миллиард долларов.
Предположим, мы захотели открыть ресторан. По каким критериям Клиент будет оценивать его? Конечно, это кухня, дизайн и обслуживание. Обычно, наибольшее количество «глюков» происходит в процессе обслуживания, т.е. там, где велик человеческий фактор. Красивенькая молоденькая официантка вроде бы привлекает Клиентов. Но у неё испортилось настроение, и вместо доброжелательного отношения, она начинает хамить. В результате, вместо привлечения происходит отваживание Клиентов. В индустрии разработки ПО такое просто недопустимо. Необходимо, чтобы специалисты разных специальностей взаимодействовали друг с другом, а барьеры в коммуникациях и всякие субъективные вещи сводились бы к нулю. Поэтому при работе в большой интернациональной команде неформальные связи между людьми заменяются формализованными бизнес-процессами, а вместо субъективных оценок (хороший, прикольный, клёвый) используются метрики и показатели качества.
В больших проектах выгоднее купить нужного специалиста на рынке, даже если его зарплата кажется чрезмерной. При съёмках кинофильма, продюсер не учит своего сценариста писать диалоги, если тот не умеет этого делать, а просто покупает сценариста для написания диалогов на рынке. Аналогичным образом поступают при разработке приложений. Если возникает недопонимание между командами из разных стран, то одну команду отправляют в длительную командировку. При миллиардной выручке затраты на командировку не имеют значения: главное – выпустить продукт в срок.
Читать полностью »
Проектная кухня. Снижение архитектурных рисков проекта
2015-02-13 в 23:49, admin, рубрики: TOC, архитектура проекта, планирование проекта, теория ограничений систем, Управление продуктом, управление проектами, управление рисками, метки: архитектура проекта, планирование проектаЗа свой опыт в разработке ПО я работал на многих проектах, и часто приходилось включаться в уже существующий проект или видеть как новая команда на моих проектах подхватывает проект с историей. Часто новый разработчик приходящий на проект и приступающий к выполнению задачи первым делом начинает плеваться на существующий дизайн. Ему кажется, что всё сделано не правильно, не очевидно и слишком переусложнено. И как результат, при выполнении задачи, начинают появляться дыры в уже разработанном дизайне и существующая архитектура начинает обрастать костылями. В конце концов, проект или его подсистему требуется переписать почти полностью. Чем старше проект, тем таких случаев может быть больше.
Также бывает и другая крайность, для реализации нового функционала или переделки существующего, один и разработчиков говорит: «Я знаю как сделать лучше!» после чего, вместо того чтобы дать идее «отлежаться» и оценить все плюсы и минусы, сразу начинает её делать. Где-то через месяц разработки может возникнуть ситуация, что чего-то он не предусмотрел, и приходится отказываться от разработки и выкидывать код или срочно искать варианты решения проблемы. Почти каждому разработчику в этом случае хочется сохранить лицо: «Как же так? Я же профессионал!» — думает он, «Если я признаю свою ошибку то все подумают, что я не настолько крут как всем говорю». И в этом случае Идея которая недостаточно проработана входит в проект и становится проблемой уже всей команды. Что также удорожает проект. А так как это становится заметно не сразу и внимания на причинно-следственные связи почти никто не обращает, то ситуация может повторяться снова и снова.
Читать полностью »
ИБ по-американски. Часть 4. Разбираемся с «подгонкой» и «перекрытиями» и завершаем этот обзор
2014-11-05 в 6:36, admin, рубрики: best practices, information security, IT-стандарты, NIST, NIST 800-53, risk management, ИБ, информационная безопасность, управление рисками 
*Оставьте свою работу на рабочем месте!*
Итак, нелёгкий путь по обзиранию созданию краткого обзора NIST SP 800-53 подходит к логическому концу. Я рад, что мне удалось совершить задуманное и написать пусть небольшой, но законченный по содержанию цикл статей, не остановившись на первой или второй части. В дальнейшем, надеюсь, получится от случая к случаю делиться с общественностью своими соображениями на тему ИБ, ИТ и аудита.
Итак, в этой статье будет наконец-то поведано о выборе набора контролей безопасности, подгонке его под нужды конкретной организации и создании так называемых перекрытий «overlays», применимых вне масштабов отдельной организации.
Ссылки на предыдущие статьи:
ИБ по-американски. Часть 1. Что такое NIST 800-53 и как выглядят контроли безопасности?
ИБ по-американски. Часть 2. А можно поподробнее о NIST 800-53 и причём тут управление рисками?
ИБ по-американски. Часть 3. Что из себя представляет базовый набор контролей безопасности и как определять критичность информационных систем?
ИБ по-американски. Часть 3. Что из себя представляет базовый набор контролей и как определять критичность систем?
2014-10-19 в 16:10, admin, рубрики: best practices, information security, IT-стандарты, NIST, NIST 800-53, risk management, ИБ, информационная безопасность, управление рисками 
*Безопасность — это отнюдь не борьба с ветряными мельницами*
В предыдущих статьях я уже достаточно подробно рассказал о публикации NIST SP 800-53. Были успешно освещены разбиение контролей на семейства, подробное описание структуры контролей безопасности, процесс управления рисками в масштабах организации и даже вкратце отдельная публикация FIPS 200.
Из-за выхода в свет Geektimes пришлось немного задержаться, но мы продолжаем двигаться дальше, и сегодня речь пойдёт о базовых наборах контролей безопасности и об определении критичности информационных систем.
Ну и конечно в комплекте аутентичные американские плакаты, посвященные безопасности.
Ссылки на предыдущие статьи:
ИБ по-американски. Часть 1. Что такое NIST 800-53 и как выглядят контроли безопасности?
ИБ по-американски. Часть 2. А можно поподробнее о NIST 800-53 и причём тут управление рисками?
Software Project Management Conference: почему важно не пропустить главную конференцию, посвященную управлению ИТ проектами
2014-08-22 в 6:19, admin, рубрики: spm conf, Блог компании Лаборатория тестирования, тестирование, управление людьми, управление проектами, управление рисками Салют коллеги!
20-21 февраля 2015г. в Москве в ивент-холле «Инфопространство» пройдет 4-я международная конференция, посвященная управлению ИТ проектами и продуктами — Software Project Management Conference (SPM Conf).
Мы уже начали публикацию первых докладов и вас ждет масса интересного и профессионального контента. Приглашаем поделиться знаниями, выступив с интересным докладом. Докладчики участвуют в конференции бесплатно!
Ну а пока о конференции словами участников.
Почему надо участвовать в конференции
О пользе и ценности участия
Читать полностью »
Давайте, наконец, задумаемся о том, что мы подразумеваем, когда говорим «активы» и «три защищаемых свойства информации»
2014-08-13 в 11:25, admin, рубрики: доступность, информационная безопасность, конфиденциальность, неотказуемость, подлинность, подотчётность, свойства информации, управление рискамиО том, о чём все и так знают
Почему-то очень многие люди говорят, что защищают три свойства информации (да, те самые: конфиденциальность, целостность, доступность).
Почему-то при оценке рисков выписывают «активы», причём только активы.
Услышав это ещё раз я не выдержал, и решил написать этот скучный и неинтересный пост о том, о чём все и так знают.
Ведь эти люди прекрасно знают, например, что такое ЭЦП. Мы что, не защищаем подлинность?
Защищаем.
Не защищаем неотказуемость?
Защищаем.
Все это знают.
Очевидно, что защищаемых свойств информации больше, чем три.
Давайте ещё раз определимся, что свойств информации не три и что когда мы выписываем «активы» — это не выписывание строк из книги учёта имущества организации.
Читать полностью »
Управление конфликтами или первая компетенция Темного Властелина
2014-08-05 в 8:06, admin, рубрики: Карьера в IT-индустрии, конфликтоген, конфликты, конфликты основателей, управление людьми, управление проектами, управление проектами и командой, управление рискамиПростите за дурашливое название, оно исключительно для привлечения внимания. Конечно же, компетенция управления конфликтами, лежит вне добра, зла и прочих оценочных суждений. А значит, сможет помочь как тем, кто будет мир порабощать, так и будет полезна для тех, кто займется его освобождением от поработителей… Шутка.
Сразу оговорюсь, что эта публикация – своего рода эссе по ментальной карте в которую я упаковал собственный опыт и приобретенные знания по теме управления конфликтами. Мой взгляд не полон и ограничен, а значит если есть какая-либо дыра в смысловой ткани темы — дайте знать, доработаю (для кого удобнее использовать для понимания ментальную карту — она в конце текста):
В этой статье рассматриваются конфликты класса человек-человек, как самый простой тип конфликтов, в отличии от других, затрагивающих более объемные системы (группа; супер-группа). Сам конфликт понимается как тип отношений между субъектами, наделёнными волей, имеющими собственные интересы и способными в силу этого занимать позицию.
Конфликт, как как частный случай
Обычная (регулярная) ситуация переходит в конфликтную, а затем кристаллизуется в конфликт, при наступлении одного или нескольких факторов:
- введении конфликтогена (раскрывается ниже);
- изменение целей у участников ситуации;
- изменении обстоятельств, которые затрагивают ценности, интересы или цели участников ситуации;
- создание участниками (или одним из) позиции, по отношению к ситуации;
И если с целями и обстоятельствами более-менее понятно, то два других пункта нуждаются в уточнении.
Читать полностью »
Controls of C.I.A
2014-07-24 в 5:52, admin, рубрики: защита информации, информационная безопасность, мануал, управление рисками Было бы очень занимательно поуправлять ЦРУ, но это доступно только товарищу Сноудену. В данной заметке (хотя размер для заметки великоват) речь пойдет про три столпа ИБ, как уже все, конечно, догадались: конфиденциальность (Confidentiality), целостность (Integrity), доступность (Availability). Материал не сильно похож на тот, что есть в учебниках российского производства, поэтому, надеюсь, будет интересным. Некоторые понятия оставляю в оригинале, те, кто в курсе в переводе не нуждаются, да и в контексте, думаю, будет все предельно ясно. Каждый из этих трех аспектов тесно связан физической безопасностью (Safety) и нарушение какого-либо из них может привести к негативным последствиям.
Читать полностью »
Семь смертных грехов руководителя проекта
2014-07-09 в 10:23, admin, рубрики: мотивация, управление людьми, управление ожиданиями, управление проектами, управление рисками
Теологи утверждают, что грех помрачает ум, ослабляет и пленяет волю, сдавливает сердце человека печалью и унынием. Блажен тот, кто осознаёт причину своего горя — греховность, а не жизненные обстоятельства или действия других людей. Правильный диагноз ведёт и к исцелению.
Читать полностью »