Ранний опыт государственного строительства большевиков и Конституция РСФСР 1918 года
7
23833
|
Официальные извинения
970
99053
|
Становление корпоративизма в современной России. Угрозы и возможности
238
80456
Специфика географически распределенного производства программного обеспечения. На примере стран СНГ 459
17193
Введение и постановка проблемы Глобализация в «экономике быстрых изменений» [1] является одним из основных трендов, и высокотехнологичные компании, в частности, создающие промышленное программное обеспечение, стремятся использовать порождаемые ей новые возможности и инструменты повышения конкурентоспособности. Примером такого инструмента - организация географически распределенных команд разработки программного обеспечения (ПО). Современные электронные инструменты поддержки производственных процессов и сопутствующих коммуникаций, как «электронная нервная система компании» [2], обеспечивают слаженность взаимодействия команд, разделенных существенными барьерами: от сотен километров до языковых и ментальных отличий. Разработка программного обеспечения (ПО) географически распределенными командами стала де-факто стандартом отрасли [3], обеспечивая очевидные конкурентные преимущества для IT-компании:
Вместе с этим возникающие в таких проектах риски требуют тщательного управления, степень предсказуемости результатов труда такой проектной команды уменьшается, ключевые параметры качества программного продукта и сроков его реализации требуют дополнительного внимания и управляющих воздействий. Таким образом, основная проблема в организации данного производственного подхода находится в области учета его особенностей и регулярной работы с сопутствующими рисками. В мировой и прежде всего американской практике такая географически распределенная разработка давно является предметом изучения [3,4], направленного на повышение эффективности планирования и управления разработкой, а значит – на повышение качества получаемого продукта. IT-индустрия России и стран СНГ развивается согласно мировым трендам, значительное количество российских вендоров ПО имеет распределенные команды разработки программных продуктов, а крупнейшие в мире разработчики программного обеспечения имеют локальные центры разработки в странах СНГ, прежде всего в России, на Украине и в Белоруссии [5]. Только в России в командах распределенной разработки работают тысячи, возможно, лучших инженеров, создающих продукты для международного рынка под брендами его ключевых игроков (Google, IBM, Microsoft, Intel, Samsung, Dell, Huawei, CISCO, SAP, Яндекс, Лаборатория Касперского, ABBYY и т.д.) В данной работе использован опыт следующих компаний (по убыванию размеров бизнеса, выраженные в годовом обороте и численности персонала): Luxoft Russia, EverNote Corp, PlayTech Ukraine, MISYS Russia, RedSys, BSC Msc, MANQRO Rus, - который представили менеджеры среднего и высшего звеньев в персональных интервью для автора в течение сентября-октября 2016 года. Данные компании ведут международный бизнес и имеют офисы в городах стран СНГ. При организации и управлении разработкой программных продуктов географически распределенными командами необходимо учитывать специфические особенности и управлять сопутствующими рисками: оценивать вероятность их наступления, планировать и применять меры, смягчающие негативные последствия. Отдельным вопросом исследования является оптимизационная деятельность, направленная на увеличение положительных эффектов от такой организации производственных процессов.
Естественные особенности разработки географически распределенными командами К данной категории особенностей относятся:
Разница в часовых поясах является одним из самых серьезных факторов, влияющих на течение всего проекта: от планирования расписания проекта до ежедневных коммуникаций. Современные IT-компании часто имеют такой разброс часовых поясов у локальных офисов, что управление данной особенностью в процессах разработки может как ускорить, так и замедлить разработку. Негативное влияние данного фактора минимизируется на уровне, прежде всего, плана коммуникаций: необходимо заранее планировать промежутки времени, удобные для участников сеансов связи. Наиболее прогрессивный подход для команд разработки - изменение времени начала и завершения рабочего дня для офисов, разница в часовых часах которых лежит в пределах 3-4 часов, чтобы совместный рабочий день занимал 6-7 часов при стандартном 8-ми часовом рабочем дне. Мировые лидеры в разработке ПО и интеграционных проектах научились приспосабливать разницу в часовых поясах, добиваясь дополнительных конкурентных преимуществ в производстве. В данной работе приводятся две наиболее перспективные производственные практики:
Следующая особенность – языковой барьер, который чаще всего имеет следующие ступени: различие родных языков разработчиков из разных офисов и различие языка бизнес-заказчика и языка проекта. Как правило, язык небольших проектов не отличается от языка заказчика. Данную особенность сопровождает риск искажения коммуникаций и даже основных положений ключевых проектных артефактов, например, функциональной спецификации требований или описаний критических дефектов. Типичными методами минимизации негативного влияния таких искажений являются: 1) Создание и ведение проектной документации на официальном языке проекта; 2) Формализация всех значимых коммуникаций (протоколы встреч, согласование результата коммуникации и т.п.); 3) Определение уровня проникновения официального языка проекта во все коммуникации в общей команде (бизнес-заказчик + менеджмент + команды разработки); 4) В международных проектах, охватывающих множество разных стран и частей света, взаимодействие с бизнес-заказчиками ведется на их родном языке, а значимые результаты коммуникаций транслируются в команды разработки на официальном языке проекта. Разница в ментальных картах участников носит наднациональный характер и сопряжено в большей степени с социально-культурными особенностями. На основе этой разницы в ментальных картах разных команд часть экспертов указывала на финансовое благосостояние и скорость восприятия новой информации. Оба фактора влияют на скорость вхождения локальных команд в решение новых задач и уровень их вовлеченности. Даже внутри одной страны (такой как, например, Россия) ментальные отличия могут сильно влиять на производства ПО. Сопутствующие риски очевидны: слабая предикативность процессов разработки ПО, слабая вовлеченность участников проектных команд в проектные задачи, отличие реализации требований в программном продукте от ожиданий бизнес-заказчиков и менеджмента проекта. Выделим список лучших практик для минимизации такого воздействия: 1) Глубокая формализация процессов и документации на всех этапах вне зависимости от особенностей применяемых парадигм разработки. Данная практика ограничивает использование гибких методологий в распределенных командах с сильными ментальными различиями; 2) Последовательная оценка совместимости (и выполнение необходимых корректировок) бизнес-заказчиков, команд разработки и менеджмента проекта. Необходимые корректировки лежат в области формализации уровня детализации требований, уровня мониторинга реализации задач, валидации требований и самого продукта, планирования резервов времени в проекте; 3) Детальное понимание ментальных особенностей различных команд разработки, как с учетом исторического проектного опыта, так и общего мнения на рынке ПО; Разница в производственных календарях у различных команд - не слишком явная, но существенная причина опозданий и снижения качества. Разница в рабочих календарях в международной компании может быть очень значительной: 1) Набор государственных и религиозных праздников России и других стран мира (кроме стран СНГ) не совпадает ни в одной дате, кроме Нового года, который празднуется в разные даты с аналогами в Китае и Индии; 2) Набор выходных дней каждую неделю в мире не совпадает; 3) Рабочие часы в сутках не совпадают в различных офисах: есть страны с 60-ти часовой (Китай) и 30-ти часовой рабочей неделей (Нидерланды) [6]. На эту разницу также накладывается разница в часовых поясах. Уменьшение влияния данного риска лежит в анализе его влияния на различных уровнях и соответствующих корректирующих воздействий:
В длительных проектах самая прогрессивная практика - использование наиболее производительных дней в неделе и недель в году: именно на них планируются самые важные задачи и вехи проекта. Пример из практики автора – перенос основных активностей по сбору требований у заказчика финансового портального решения, в который были вовлечены офисы из России и Европейского Союза, с конца декабря на середину января следующего года. Этот сдвиг связан с несовпадающими рождественскими праздниками в России и Европе, а аналитики компании в это время осуществляли погружение инженеров разработки и управления качеством в предметную область – финансы и банковскую деятельность. Сдвиг в датах был компенсирован упорной работой в первые месяцы нового года.
Организационно-экономические особенности разработки географически распределенными командами К данным особенностям относятся:
Управление коммуникациями географически распределенной командой - наиболее важная практика, обеспечивающая успех проекта и оказывающая глобальное влияние на производственные и управленческие процессы в проекте. В основе таких коммуникаций лежат электронные каналы: почта, группы в месенджерах, голосовые средства связи, собрания команды в формате конференц-звонков. Электронные каналы связи имеют определенные недостатки: 1) Дополнительные организационные усилия в микро-менеджменте, когда каждый самый небольшой вопрос должен сопровождаться законченной формализованной коммуникацией вплоть до его разрешения; 2) Затрудненность получения обратной связи от подчиненных в вертикальных коммуникациях, особенно в ее эмоциональной составляющей; 3) Большой процент помех и искажений в групповых формах коммуникаций, особенно в формате конференц-звонков с большой аудиторий участников и на неродном языке для участников. Наиболее прогрессивная практика в электронных коммуникациях - видео-конференции. Они требуют более сложного аппаратного и программного обеспечения, но позволяют:
Таким образом, построение плана коммуникаций в проекте с географически распределенными участниками или командами разработки требует особого внимания руководителя проекта. Значительная часть рисков в области искажения информации между участниками проекта должна быть снята именно в этом документе. Пример из практики автора – особенности коммуникационного плана в проекте внедрения в российской финансовой группе решения для предоставления брокерских и финансовых услуг. Решение разрабатывалось тремя офисами международной IT-компании в разных странах, официальный язык проекта был русский, но часть разработчиков не говорила на нем. План коммуникаций проекта не только содержал типичные разделы для такого документа (например, матрицу заинтересованных участников или план эскалации проблем), но и описывал полный перечень и правила пользования электронными средствами коммуникаций. Для проекта был создан набор групп в Skype, проектные и групповые почтовые рассылки, определены форматы групповых встреч с заказчиком и внутри команд разработки. Члены проектной команды обязательно подтверждали все договоренности на встречах или по телефону электронными письмами, использовали общие группы в Skype для проектного взаимодействия и треккинга общих задач, а также почтовые рассылки - для групповых коммуникаций. Для мини-команд в локальных офисах создавались отдельные группы в Skype для обсуждения вопросов, ограниченных их собственной зоной ответственности. Управление персоналом в географически распределенных командах проектов разработки сопряжено с получением двух наиболее значимых плюсов: экономия на зарплате и доступ к специалистам с редкой или очень высокой квалификацией [7]. Наиболее важно первое: в странах с развивающейся экономикой (Россия, Украина, Индия, Китай) ожидания сотрудников существенно ниже, чем в Западной Европе, США или Австралии. А внутри таких стран есть регионы с еще меньшими ожиданиями, что позволяет «столичным» компаниям открывать недорогие региональные офисы. Вместе с тем в каждом региональном центре есть часть сотрудников, обладающий редкой специализацией или очень высокой квалификацией. Их переезд из таких регионов не всегда оптимален или возможен, однако компания может нанимать их на удаленную работу, впоследствии формируя с их участием региональные офисы. Таким образом, команда проекта может получить яркий состав профессиональных участников при небольшом внутреннем бюджете. Затянувшиеся экономические кризисы в Беларуси, Украине и России усиливают мотивацию компаний стран СНГ к оптимизации затрат и повышению конкурентоспособности [8]. Один из действенных подходов в данном направлении –открытие региональных офисов с низкими эксплуатационными расходами и зарплатами. Кроме того, управление персоналом подразумевает учет следующих факторов:
Сопутствующие риски в данном вопросе лежат в поле недостаточной мотивации и вовлеченности в проекты текущих сотрудников локальных офисов и ошибках при работе с командами, когда усилия по набору или оптимизации персонала наносят вред в силу несогласованности действий различных менеджеров. Минимизация данных рисков достигается с помощью административных мер, среди которых одной из самых действенных является появление локальных тимлидов (командных лидеров) в каждой группе проекта. Тимлид – это высококвалифицированный специалист, участвующий в управлении одной из практик проекта (аналитика, разработка, тестирование и т.п.) в части распределения задач среди специалистов и мониторинга их исполнения. Он должен сочетать высокую компетентность в технологиях и\или предметной области, личную ответственность, лидерские качества и опыт работы в конкретной организации или проекте [9]. Именно локальные тимлиды занимают проактивную позицию в решении общих проблем проекта, отвечают за трудовую дисциплину, наличие необходимой групповой экспертизы в предметной области и технологиях разработки, а также за усвоение корпоративных ценностей (включая проектный уровень) в локальной команде. Проблемой является свойственный многим из них менталитет «маленького царька», с которым необходимо методично и последовательно бороться, используя интеграционные и мотивационные инструменты как в личных, так и в групповых коммуникациях. В российских компаниях выбор локальных тимлидов часто связан с их специальными навыками или опытом работы в организации. Но без развитого чувства ответственности и лидерских качеств такой выбор ошибочен и ведет к накапливанию серьезных проблем. Пример из личного опыта автора: российский системный интегратор проводил проект кастомизации и внедрения сложного программного продукта, решающего задачи информационной безопасности, в крупном российском банке. Локальным тимлидом в одной из частей команды был один из самых опытных сотрудников в организации, эксперт в предметной области и технологиях разработки, но лишенный лидерских качеств и ответственности по взятым проектной командой обязательствам. Используемые технологии были абсолютно новыми на российском рынке, а взятые контрактные обязательства не оставляли избыточного времени для различного рода исследований и обучения, в которые команда вопреки рациональной логике погрузилась с самого начала проекта. В результате в течение нескольких месяцев механизмы распределения и мониторинга задач среди разработчиков не были построены, а намеченные контрольные точки в проекте были упущены. Нечеткое понимание уровня ответственности по взятым интегратором обязательствам, в частности, со стороны тимлида, привело к его вынужденной замене. Она потребовала дополнительных организационных усилий, частично демотивировала команду разработки, затруднила отношения с заказчиком. Вопрос трудовой дисциплины в географически распределенных командах стоит очень остро: члены команд в небольших офисах, разделенные с руководителями проектов расстоянием, часовыми поясами, языком и ментальностью, отделены от контроля трудовой дисциплины, отработки положенных часов, своевременного прихода и на работу и т.п. Хотя для некоторых исследователей и практиков IT-бизнеса это кажется малозначимым [10], падение дисциплины в локальных командах часто трудно остановить, их члены теряют вовлеченность, приобретают собственные цели, начинают относиться к своим обязанностям формально. Решение данной проблемы лежит в следующих плоскостях: 1) Четкий и последовательный мониторинг выполненных задач; 2) Частые личные встречи с руководством в различных форматах в локальных офисах: рабочие, обучающие, мотивирующие, неформальные; 3) Контроль трудовой дисциплины с помощью информационных систем учета рабочего времени и благодаря усилиям локальных тимлидов. Руководитель проекта должен координировать свои усилия с локальными тимлидами и повышать их личную заинтересованность в успехе проекта. Методы мотивации зачастую нематериальны, в т.ч. находятся в области согласования проектных и личных целей участников команды управления проектом. Административная и техническая поддержка проектных команд в разных офисах компании может существенно различаться, что существенно влияет на производственные процессы. Материально-техническая поддержка центрального офиса (в котором, как правило, работает менеджмент) часто существенно выше, чем в локальных офисах, где расположены группы разработки. Это влияет на:
Преодоление различий в административной и технической поддержке связано с работой менеджмента в локальных офисах, работой службы управления персоналом, усилиями тимлидов. В большинстве российских компаний или российских офисах международных компаний эта проблема не попадает в поле зрения первых лиц или совета директоров и потому должна решаться локально.
Производственные особенности разработки географически распределенными командами Данные особенности и связанные с ними риски относятся ко всем производственным практикам: от создания ПО до разработки сопроводительной документации и поддержки текущей версии решения в промышленной эксплуатации. Это наложение естественных и организационных особенностей на производственные практики, изменяющие последние и требующие дополнительного анализа и мониторинга производственных процессов, а также управления возникающими рисками. Влияние таких рисков может быть нивелировано дополнительными организационными усилиями и дополнительной формализацией процессов в производственных практиках. Наиболее заметное влияние совокупность особенностей и рисков оказывает на:
Анализ проектных задач должен учитывать как ранее указанные факторы, например, естественные особенности, так и необходимость правильной декомпозиции задач. Нахождение аналитиков проекта в одной локации с заказчиком существенно уменьшает искажения информации на стадии сбора и анализа требований. При этом постановка задач командам разработки должна быть непрерывным и согласованном процессом, в течение которой отсутствие личных контактов компенсируется отслеживанием ЖЦ каждой задачи в инструментах поддержки процессов разработки (MS Project Plan, Jira, Redmine и т.п.). Обратная связь по исполнимости задач с нужным уровнем качества и в заявленные сроки затруднена, электронные каналы коммуникаций не передают эмоциональный контекст работы над задачами разработки ПО. Преодоление этих недостатков лежит в области формализации задач, частого сбора промежуточных релизов и валидации программного обеспечения, дополнительных экспертиз программного кода, пользовательских интерфейсов системы и проектных документов. Одной из спорных практик является распределение задач по географическим локациям в надежде, что сработавшиеся мини-команды лучше решают отделенные от общего потока задачи разработки ПО. На практике разделение на мини-команды по сути специализации (анализ, проектирование, кодирование тестирование и т.п.) часто более продуктивно, чем по географической локации. Однако ряд экспертов, наоборот, уверен, что мини-команды в локальных офисах способны эффективно решать отдельные ветки задач, т.к. находятся в тесном взаимодействии, выше их производственная дисциплина и вовлеченность в задачи. Постановка проектных задач в географически распределенных командах связана со следующими особенностями:
Для успешной реализации первой особенности используют строгие правила работы с автоматизированными инструментами поддержки процессов разработки, в которых осуществляется мониторинг исполнения каждой задачи. При этом дополнительная детализация задачи часто сопровождается созданием эскизов пользовательских интерфейсов и описанием на родном языке разработчиков в дополнение к описанию на официальном языке проекта. Основная роль в реализации второй особенности принадлежит локальному тимлиду, который должен знать личные и производственные характеристики членов команд разработки в локальных офисах. Правильная декомпозиция задач снижает необходимость частых контактов между сотрудниками разных офисов, что экономит организационные усилия и снижает излишний информационный фон. С данной проблемой связана проблема промежуточного контроля результатов, для решения которой недостаточно устных коммуникаций на общих встречах проектных команд в видео-конференциях или общих конференц-звонках. При этом используемые электронные каналы коммуникаций часто приводят к искажениям информации, а разницы в часовых поясах и рабочих календарях затрудняют быструю ликвидацию таких искажений. Для промежуточного контроля результатов необходимо строгое отслеживание статуса каждой задачи в автоматизированных системах управления проектами. С одной стороны, такой промежуточный контроль занимает существенно больше времени и связан с микроменеджментом, с другой, это позволяет уже на ранних этапах определить отставания в задачах или несоответствие программного продукта требованиям или ожиданиям заказчиков. Управление качеством программного решения, разрабатываемого географически распределенной командой, сопряжено с работой над дефектами в течение всего их жизненного цикла с учетом следующих особенностей: 1) Необходимость формализованного подхода с использованием систем баг-треккинга в решении почти 100% инцидентов; 2) Описание дефектов имеет значительную долю искажений, связанных с языковым барьером и отсутствием горизонтальных связей; 3) Значительные временные затраты (простои), связанные с разрывами по промежуткам времени, удобным для коммуникаций между участниками проекта. Тотальное использование баг-треккинга только на первый взгляд кажется неудобством: при продолжительности проекта в несколько лет и многочисленных циклах регрессионного тестирования полная база ранее появлявшихся дефектов позволяет экономить время в разборе причин новых инцидентов, особенно повторяющихся в разных географических локациях. Искажения в описании дефектов должны решаться административными методами, когда для каждого дефекта в проекте существуют правила его описания (например, использовать только язык проекта, описывать сценарий возникновения, прикладывать скриншот пользовательского интерфейса и т.п.). Такие правила вынуждают инженеров по обеспечению качества ПО на должном уровне документировать дефекты, а необходимость в личном общении инженеров по каждому дефекту резко снижается. Временные простои при необходимом обсуждении и исправлении дефектов могут нивелироваться с помощью организации гибкого рабочего дня команд обеспечения качества ПО и назначения регулярных коммуникационных сессий заинтересованных участников процесса. Самая прогрессивная практика, позволяющая реализовать преимущества разработки ПО географически распределенными командами, – создание «удлиненного дня разработки». Мировые лидеры рынка ПО применяют ее с использованием гибридных методологий (типичные этапы цикла «анализ-разработка-тестирования-валидация» ежедневно повторяются с минимальными перерывами работы команды в сутках). Такой идеальный сценарий при ежедневной сборке релизов и фрагментации задач на 8-ми часовые периоды работы подразумевает активность различных специалистов в дневное время в своем часовом поясе и ежедневную передачу результатов следующей группе, которые начинают свой рабочий день в другом офисе и часовом поясе. Обычно аналитики и бизнес-заказчики находятся в одной и той же географической локации, остальные команды разработки «отстают» от них в своих часовых поясах. Примерную последовательность работ можно описать так:
Существенными трудностями в такой организации производства ПО являются:
Однако выявленные трудности могут быть нивелированы организационными и административными мерами, в том числе выделением дополнительных полномочий для ответственных тимлидов в каждом локальном офисе. Данный сценарий в его идеальном воплощении возможен лишь в очень устойчивых по составу и сработавшихся командах при наличии формализованных и повторяющихся производственных процессов и при очень незначительном изменении требований в течение проекта. Поддержка решений, которые уже стоят в промышленной эксплуатации, командами инженеров в различных локациях имеют свои достоинства и недостатки. С одной стороны, возможно создание экономически эффективной распределенной команды поддержки решения - «круглогодичная поддержка дневными сменами инженеров». Мировые лидеры рынка ПО уже построили этот бизнес-процесс так, что всю совокупность промышленных сред (на разных континентах и в разных вариантах) поддерживают только дневные смены инженеров, более экономичные и эффективные. Неоспоримое достоинство данной практики в том, что сообщения о проблемах заказчика или пользователей в эксплуатации ПО в промышленной среде поступают всегда в офис, где в настоящий момент светлое время суток и активный рабочий день. Такая смена решает поступающие инциденты весь день, а по его истечению передает весь фронт работ (т.е. текущие инциденты, статусы критичных дефектов, работу над стабилизацией среды, информационные запросы и т.д.) следующей смене, у которой начинается активный рабочий день в ее локации. Очевидно, что дневные смены работают более эффективно и экономически менее затратны, чем ночные, при этом заказчики и пользователи информационных систем по всему миру получают лучший и бесперебойный сервис поддержки. С другой стороны большинство компаний не обладает организационными возможностями для такого бизнес-процесса и рассматривает процессы поддержки в географически распределенных командах как возможность снизить расходы. Некоторые нишевые мировые лидеры создают локальные центры поддержки решений в локациях с невысокими зарплатными ожиданиями (Азия, Африка), которые со временем наращивают внутреннюю специализацию в конкретном продукте. Тогда схема поддержки выглядит так: 1) Прием и разбор инцидентов происходит в той же стране или городе, где расположен рынок сбыта ПО (или головные офисы корпоративных Заказчиков); 2) Критичные дефекты исправляются в кооперации локального офиса и центра поддержки данного программного решения; 3) Некритичные дефекты отправляются на исправление в центр поддержки. Такая организация поддержки решений в промышленной эксплуатации экономически выгодна для поставщика решения, но создает некоторые проблемы. Прежде всего, заметны существенные временные потери, которые затрагивают исправление всех дефектов, находящихся в совместном поле ответственности офисов из разных стран. Эти временные затраты связаны как с естественными причинами, вроде разницы часовых поясов, так и с обычно низкой вовлеченностью специалистов центра поддержки в проблемы локальных заказчиков. Кроме того, ментальные и языковые барьеры приводят к искажению в описании дефектов, а взаимное недовольство инженеров локальных офисов и инженеров центра поддержки снижают их эффективность. Преодоление указанных проблем лежит в области административного регулирования – только жесткие бизнес-процессы и нормированные по времени трудовые операции могут повысить качество поддержки глобальных решений. С другой стороны, необходимо проводить корпоративные мероприятия, укрепляющие горизонтальные связи между инженерами, позволяющие им понять, что они решают важную и общую проблему – востребованность продукта на рынке и удовлетворенность потребителей. * * * Таким образом, организация производства ПО в проекте с географически распределенной командой требует дополнительного учета значительного количества факторов и особенностей, активного управления дополнительными рисками, очевидных изменений в управлении персоналом. Управление рисками в таком проекте усложняется, требует большего внимания руководителя и более сложного комплекса мер реагирования и корректирующих воздействий, а значит – больших издержек. Это означает, что экономическая целесообразность перехода к такой модели должна быть явной, обоснованной и своевременной в жизненном цикле развития бизнеса IT-компании.
Список литературы 1. Авдокушин Е. Ф. «Новая экономика»: сущность и структура: Экономическая теория на пороге XXI века-5. Неоэкономика / Под ред. Ю. М. Осипова и др. М., Юристъ. 2001. 624 с. 2. Gates, Bill (2009) Business @ the Speed of Thought. Grand Cantral Publishing. 3. Massey, A.P.; Montoya-Weiss, M.M.; and Hung, Y.-T. Because me matters: Temporal coordination in global virtual project teams. Journal of Management Information Systems, 19, 4 (Spring 2003), 129–156 4. A.Espinosa, S.A.Slaughter, R.E.Kraut, J.D.Hersleb Team Knowledge and Coordination in Geographically Distributed Software Development Journal of Management Information Systems , 2007 vol.24-1, pp 135-169 5. Russian software developing industry and software exports, 9-th survey, 2012 p.61-62 URL: http://www.russoft.ru/files/RUSSOFT_Survey_12_en.pdf 6. Трудоголики против лентяев: сколько длится рабочая неделя в разных странах. Материалы РИА Новости URL: https://ria.ru/society/20160530/1440664540.html 7. Ch. Chakraborty, D. Dutta Indian Software Industry: Growth Patterns, Constraints and Government Initiatives, 2006. Available at: https://crawford.anu.edu.au/acde/asarc/pdf/papers/2002/WP2002_06.pdf. 8. Pashchenko, Denis (2015) Problem of software development process standardization — comparing CIS and CEE regions, World of New Economy, vol.2 pp.95-100 9. Hofstede, Geert, Hofstede, Gert Jan, and Minkov, Michael. (2010). Cultures and organizations: Software of the Mind (3rd ed.). New York: McGraw-Hill. 10. С. Архипенко Руководство командой разработчиков программного обеспечения. Прикладные мысли URL: http://www.arkhipenkov.ru/resources/sw_team_management.pdf
References
комментарии - 459
забанить сайт Very good write ups. Kudos! Well spoken genuinely. . Seriously loads of beneficial material. Wonderful posts. Many thanks! Thanks. Useful information! Amazing stuff, Cheers! Reliable advice. Many thanks. Wonderful facts. Thanks! Seriously loads of superb advice! Thanks. Lots of data. Awesome advice. With thanks! Kudos. Terrific information! Really a lot of helpful tips. Many thanks, Awesome information. Thanks, I enjoy it. Fantastic write ups, With thanks! Amazing posts. Thanks a lot. Whoa tons of beneficial information. Мой комментарий
|
Подписка
|
Добрый день, уважаемая редакция!
Познакомьте меня, пожалуйста, с Павловским Юрием. Статья моя, а вот дописанного первым господина Павловского я не знаю, и его часть написанного в моем тексте обнаружить не смог.
Может быть, после знакомства мы вместе что-нибудь действительно напишем.