Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 171 сообщений
Cообщения с меткой

разработка программного обеспечения - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 2

Суббота, 19 Августа 2017 г. 13:50 (ссылка)

С частью 1 можно ознакомиться, перейдя по ссылке



Рекомендации по проектированию спецификаций требований с примерами



То, о чем не говорят, каждый понимает по-своему


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



Готовим читателей к знакомству со спецификациями



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



Пример обзора документа:





Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
Читать дальше ->

https://habrahabr.ru/post/335924/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 1

Четверг, 17 Августа 2017 г. 16:37 (ссылка)

По мотивам моей статьи, изданной ранее…

Вступление



Получить бы медаль, а уж с обратной ее стороной найдем, что делать.

(Георгий Александров)


В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей, на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.



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

https://habrahabr.ru/post/335830/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Due date как компонента ответственности в процессе разработки

Четверг, 17 Августа 2017 г. 10:25 (ссылка)



В продуктовой разработке постоянно и довольно остро стоит вопрос эффективности. Как построить процесс так, чтобы он был оптимален с точки зрения бизнеса, роста сотрудников, изменяемости, прозрачности и многих других факторов? Где та самая «серебряная пуля», которая позволит решить сразу все проблемы и избавит вас как руководителя от головной боли?



На звание этой «серебряной пули» по очереди претендуют модные (и не очень) методологии разработки: Scrum, Kanban, XP, RAD, FDD и т. п. Регулярно появляются новые способы и подходы, фреймворки и инструменты. Бизнес-консультанты приходят в компании и делятся своими ноу-хау за немалые деньги, рассказывая, как правильно. А при этом хорошо бы ещё и дёшево, не так ли?



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



Давайте подумаем, что требуется от процесса, какие проблемы нужно решить и какие подходы для этого используют. А заодно я расскажу о том, как делаем мы в Badoo. Это уже третий мой пост подряд в нашем блоге на Хабре. Но на всякий случай представлюсь снова: я – Илья Агеев, руковожу QA в Badoo.

Читать дальше ->

https://habrahabr.ru/post/335622/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как workflow разработки влияет на декомпозицию задач

Среда, 09 Августа 2017 г. 17:05 (ссылка)



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



Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.



Почему это важно?



Необходимо помнить о том, что процесс разработки – это не только непосредственно сеанс написания кода. Когда мы говорим о разработке, я призываю смотреть на весь процесс целиком, начиная от постановки задачи и заканчивая стабильной работой фичи у наших пользователей. Если не брать в расчёт все этапы, которые предшествуют кодированию и следуют за ним, то очень легко можно попасть в ситуацию, когда все что-то делают, выполняют свои KPI, получают бонусы, а результат получается плачевный. Бизнес загибается, конкуренты «душат», но при этом все – молодцы.



Почему так происходит? Всё просто: человеческая психология заставляет людей смотреть на ситуации с точки зрения собственного комфорта. Разработчику не всегда хочется думать о том, что будет с кодом после его написания. Решил задачу – и хорошо. Его крайне редко это интересует (именно поэтому мы, айтишники, и работаем в этой отрасли – наша мотивация в основном держится на интересности задач), ведь в отношениях с людьми столько неопределённости. Гораздо более комфортно многие разработчики чувствуют себя, сидя за компьютером и сосредоточившись на решении своей собственной интересной задачи – блокчейнах с нейросетями – им совсем не хочется отвлекаться и думать о каких-то продакт-менеджерах, дедлайнах, пользователях, которые потом будут использовать их гениальное произведение (а то ещё и критиковать начнут!).



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



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



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



Хороший пример – написание юнит-тестов. Зачем мне тратить своё драгоценное время на написание тестов, если у нас есть тестировщики, которые потом и так всё протестируют? А затем, что юнит-тесты необходимы не только для облегчения процесса кодинга – они нужны также и на последующих этапах. И нужны как воздух: с ними процесс интеграции и проверки регрессии ускоряется в десятки, сотни раз, на них базируется пирамида автоматизации. И это даже если не брать в расчёт ускорение вашей собственной работы: ведь «потрогав» код в каком-то месте, вам самому нужно убедиться в том, что вы ненароком что-нибудь не сломали. И один из самых быстрых способов это сделать – прогнать юнит-тесты.



Workflow



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



Стоит ли говорить, что если изначально договориться о процессе, не принимая во внимание весь жизненный цикл фичи, то можно получить замедление и «грабли» в будущем? Особенно если учесть рост проекта и компании. О преждевременной оптимизации не забываем, но если есть процесс, который хорошо работает на разных масштабах, то почему бы его не использовать изначально?



Говоря о workflow разработки, многие, кто использует Git, сразу вспоминают (всуе) о некоем «стандартном git-flow», считая его идеальным, правильным, и часто внедряют его у себя. Даже на конференциях, где я выступал, рассказывая про workflow в Badoo, меня несколько раз спрашивали: «Зачем вы изобрели своё, почему не используете стандартный git-flow?» Давайте разбираться.





Во-первых, обычно, говоря про этот флоу, имеют в виду вот эту картинку. Я взял её из статьи Vincent Driessen “A successful Git branching model”, в которой описывается схема, довольно успешно работавшая на нескольких его проектах (было это в далёком 2010 году).



Сегодня некоторые крупные игроки на рынке хостинга кода вообще предлагают свой флоу, критикуя «стандартный git-flow» и описывая его недостатки; дают свои схемы, рекомендации, приёмы.



Если же поискать на git-scm.com (хорошо бы вообще погуглить), то с удивлением можно обнаружить, что никакого рекомендованного (и уж тем более «стандартного») workflow не существует. Всё потому, что Git – это, по сути, фреймворк для систем хранения версий кода, и то, как вы организуете это самое хранение и совместную работу, зависит только от вас самих. Всегда нужно помнить о том, что, если какой-то флоу «взлетел» на каких-то проектах, это вовсе не означает, что вам он тоже полностью подойдёт.



Во-вторых, даже у нас в компании у разных команд разный флоу. Флоу разработки серверного кода на PHP, демонов на С/ С++ и Go, флоу мобильных команд – они разные. И пришли мы к этому не сразу: пробовали разные варианты, прежде чем остановиться на чём-то конкретном. К слову, отличается в этих командах не только workflow, но ещё и методологии тестирования, постановки задач, релизы и сам принцип доставки: то, что поставляется на ваши личные серверы и на компьютеры (смартфоны) конечных пользователей, не может разрабатываться одинаково по определению.



В-третьих, даже принятый workflow является скорее рекомендацией, чем непререкаемым правилом. Задачи у бизнеса бывают разные, и хорошо, если вам удалось выбрать процесс, покрывающий 95% случаев. Если же ваша текущая задача не вписывается в выбранный флоу, имеет смысл посмотреть на ситуацию с прагматической точки зрения: если правила мешают вам сделать эффективно, к чёрту такие правила! Но обязательно посоветуйтесь с вашим менеджером перед принятием окончательного решения – иначе может начаться бардак. Вы можете банально не учесть какие-то важные моменты, которые известны вашему руководителю. А, возможно, всё пойдёт как по маслу – и вы сумеете изменить существующие правила так, что это приведёт к прогрессу и станет залогом роста для всех.



Если всё так сложно, да ещё и флоу – это не догма, а всего лишь рекомендация, то почему бы не использовать одну ветку для всего: Master для Git или Trunk для SVN? Зачем усложнять?



Тем, кто смотрит на проблему однобоко, этот подход с одной веткой может показаться очень удобным. Зачем мучиться с какими-то ветками, париться со стабилизацией кода в них, если можно написать код, закоммитить (запушить) в общее хранилище – и радоваться жизни? И правда, если в команде работает не очень много человек, это может быть удобно, поскольку избавляет от необходимости слияния веток и организации веток для релиза. Однако данный подход имеет один очень существенный недостаток: код в общем хранилище может быть нестабильным. Вася, работающий над задачей №1, может легко сломать код других задач в общем хранилище, залив свои изменения; и пока он их не исправит/ не откатит, код выкладывать нельзя, даже если все остальные задачи готовы и работают.



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



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



Feature branches



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



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



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



Ещё опаснее конфликты, связанные с логикой кода, когда SCM сливает код без проблем (ведь по строкам в файлах конфликтов нет), но из-за изоляции разработки какие-то общие методы и функции в коде изменили своё поведение или вообще удалены из кода. В компилируемых языках проблема, как может показаться, стоит менее остро – компилятор валидирует код. Но ситуации, когда сигнатуры методов не поменялись, а логика изменилась, никто не отменял. Такие проблемы сложно обнаруживать, и они ещё более отдаляют счастливый релиз и заставляют перетестировать код много раз после каждого слияния. А когда разработчиков много, кода много, файлов много и конфликтов много, всё превращается в сущий ад, ибо пока мы исправляли код и перепроверяли его, основная версия кода уже ушла далеко вперёд, и надо всё повторять заново. Вы всё ещё не верите в юнит-тесты? Хе-хе-хе!



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



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



Параллельная работа



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



Тут многое зависит от вашего цикла релизов, потому что моментом завершения задачи мы считаем момент попадания её на продакшн. Ведь только этот момент гарантирует нам, что код стабилен и работает. Если не пришлось откатывать изменения с продакшна, конечно.



Если цикл релизов быстрый (несколько раз в день вы выкладываетесь на свои серверы), то вполне можно сделать фичи зависимыми друг от друга по стадиям готовности. В примере с Петей и Васей выше создаём не две задачи, а три. Соответственно, первая звучит как «меняем общий метод так, чтобы он работал в двух вариантах» (или заводим новый метод для Пети), а две другие задачи – это задачи Васи и Пети, которые могут начать работу после завершения первой задачи, не пересекаясь и не мешая друг другу.



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



В этом случае можно использовать промежуточную ветку, общую для нескольких разработчиков, но ещё недостаточно стабильную, чтобы быть выложенной на продакшн (Master или Trunk). В нашем флоу для мобильных приложений такая ветка называется Dev, на схеме Vincent Driessen она называется develop.



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



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



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



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



Feature flags



Но как же быть в ситуации, когда новое изменение бизнес-логики – большое? Только на программирование такой задачи может уйти несколько дней (недель, месяцев). Не будем же мы сливать в общее хранилище недоделанные куски фич?



А вот и будем! В этом нет ничего страшного. Подход, который может быть применён в этой ситуации, – feature flags. Он основан на внедрении в код «выключателей» (или «флагов»), которые включают/ выключают поведение определённой фичи. К слову, подход не зависит от вашей модели ветвления и может использоваться в любой из возможных.



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



Последней задачей в процессе разработки новой большой фичи в этом случае будет задача «включить фичефлаг» (или «добавить пункт меню» в примере с новой страницей).



Единственное, что нужно иметь в виду, используя фичефлаги, – это увеличение времени тестирования фичи. Ведь продукт необходимо протестировать два раза: с включённым и выключенным фичефлагом. Сэкономить тут можно, но действовать следует крайне деликатно: например, тестировать только то состояние флага, которое выкладывается пользователю. Тогда в процессе разработки (и выкладки по частям) задачи её тестировать вообще не будут, а проведут тестирование только во время проверки последней задачи «включить фичефлаг». Но тут надо быть готовым к тому, что интеграция кусков фичи после включения флага может пройти с проблемами: могут обнаружиться баги, допущенные на ранних этапах, и в этом случае поиск источника проблемы и устранение ошибок могут дорого стоить.



Заключение



Итак, при декомпозиции задач важно помнить три простых правила:




  1. Задачи должны быть в виде логически завершённых кусочков кода.

  2. Эти кусочки кода должны быть маленькими и должны максимально быстро попадать в общий код.

  3. Эти кусочки должны разрабатываться параллельно и выкладываться независимо друг от друга.



Куда уж проще? Кстати, независимая выкладка, на мой взгляд, — самый важный критерий. Из него так или иначе проистекают остальные пункты.



Желаю удачи в разработке новых фич!


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335254/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Чтобы ваша культура вмещала всех, попробуйте работать меньше

Среда, 05 Июля 2017 г. 13:25 (ссылка)

Моя первая работа в области разработки ПО заключалась в программировании на С++ для компании J.D. Edwards, которая сейчас является частью Oracle. Я проработал там с 1996 по 2000 год. Она настолько отличается от любой работы, на которой я был с того времени, с настолько разных сторон, что я всегда отношу ее к короткой “доинтернетной” фазе моей карьеры. Но есть такой момент – команда, в которой я работал, была самой разнообразной из тех, в которых я работал. А может даже из тех, с которыми лишь приходилось иметь дело, в рамках всей нашей отрасли.



Почему? Думаю, у меня есть ответ.



Культура J.D. Edwards и стандарты рабочего пространства были заимствованы напрямую из IBM. Пиджак и галстук обязательны для мужчин. Каждый день. Можно было оставить пиджак на спинке стула в кубикле всю неделю, уезжать домой и приезжать обратно в рубашке, но если ты не забрал пиджак домой на выходные и не менял его каждую неделю, тебе бы указали на это. Если ты начал появляться на работе в 9 вместо 8:30, на это обязательно бы указали. Ништяки? Бесплатная газировка. Пятницы в стиле кэжуал неохотно вводились лишь под давлением интернет бума, потому что иначе становилось труднее нанимать людей. Я любил мою работу и ненавидел дресс-код и режим.



Мои друзья-хипстеры нанимались в интернет-стартапы и носили джинсы, кроссовки и футболки с ироническими рисунками и надписями. Их офисы были в новом хип-районе в центре, с пинг-понгом и настольным футболом (бесплатные обеды еще только дело будущего). Они дружили со всеми своими коллегами, появлялись на работе в 10:00 и обычно заваливались в бар все вместе сразу после работы. Мне было очень завидно… но за разницей в дресс коде я не увидел различий в разнообразии в команде.



Я уже сказал ранее, что до сегодняшнего дня моя команда в J.D. Edwards была самой разнобразной, в которой я работал. Мой первый босс был иммигрантом из Африки, вторым боссом была женщина «мамочка сорок с чем-то». В нашей команде степень разнообразия была высоким по всем параметрам – пол, раса, религия, возраст, наличие детей, происхождение, сексуальная ориентация, инвалидность, статус ветерана. Это была очень талантливая и трудолюбивая группа. В то время я не знал других команд, поэтому это не казалось мне чем-то из ряда вон выходящим.



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



Я ушел в 2000. Был легкомысленным. Я нашел работу в софтверной хип-компании. Офис был в центре. Мои новые коллеги были клевыми. Они носили футболки с ироничными рисунками и текстами. Появлялись на работе в 10 или позже, работали сумасшедшее количество часов. По пятницам, и многим другим дням, после работы они шли все вместе попить крафтового пива, потом шли домой в крутые лофты или направлялись прямо на инди-рок шоу.



Они все были белыми, молодыми, у них не было детей, большинство из них были мужчинами. Женщины были в HR или в отделе качества (QA), или создавали контент. Менеджеры по разработке, были, в основном, белыми мужчинами немного постарше. Менеджерами по качеству были белыми женщинами, тоже слегка старше.



Тьфу.



Моя новая компания, грубо говоря, выглядела как вся наша отрасль, которой мы так недовольны, и в которой сейчас начинает что-то меняться.



Я уже не работал там в момент, когда крах доткомов раскидал нас кого-куда. Моя «настоящая» карьера в отрасли началась уже после, то есть J.D. Edwards и эта другая компания всегда казались мне прелюдией к тому, что я не очень-то успел осознать. Вчера все поменялось.



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



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



Я увидел преимущества концепции «строго бизнес» в те семь лет, что был в Fog Creek Software и ее дочерней компании, Trello.



Я перешел в Fog Creek в 2008, из Google New York, где я работал до этого пять лет. Google NY имел смешанную корпоративную культуру: культуру продаж и техническую, от вас ожидали приходить на работу в 10, работать до 8, потом заваливаться в бар со своими коллегами. Работа в такой компании, о которой все говорят, будоражила, нравилось ощущение что, что мы были частью чего-то очень большого. Иногда я работал сумасшедшее количество часов, путешествовал по всему миру. Это было здорово. У меня до сих пор осталось много хороших друзей с того времени. Я не говорю, что в Google NY не было разнообразия, как в той интернет-компании, упомянутой выше, но образ жизни был всепоглощающим. В первую очередь, мы были гуглерами.



Когда я пришел в Fog Creek, нас было всего с десяток. У меня был культурный шок. Там было некоторое количество парного программирования, но не так много разговоров «у кулера». Все разрабы собирались на обед в полдень, потом шли обратно в свои офисы и закрывали двери. В 5:00 каждый вставал и уходил. Я был в абсолютном замешательстве. Я пробыл в той всепоглощающей среде настолько долго, что был немного разочарован таким внезапным ограничением роли работы в моей жизни.



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



«Ты знаешь, как мы называем люлей, которые работают после 5 вечера?», спросил он.



«Как?»



«Болваны.»



У меня вырвался смешок, но он говорил серьезно. Он не хотел, чтобы кто-то работал в необязательные рабочие часы, потому что вдруг, все могут начать этого придерживаться. Я все понял, наладил свой график так, чтобы он был с 9 до 5 и придерживался его.



В то время, Fog Creek был маленьким и не имел большого разнообразия. Через годы, мы выросли и создавали продукты, запускали отдельные компании, всегда придерживаясь разумного графика, стараясь все делать профессионально.



Где-то в 2011 году, запахло переменами. Люди в отрасли были недовольны недостатком разнообразия. Пост в блоге нашей компании, «Girls Go Geek, Again», стал самым читаемым и самым расшариваемым в нашей истории (насколько я знаю, он остается в топ-3). Мы сильно хотели построить разнообразие при помощи нашего процесса найма: начали с нашей программы стажировки, которую так много заимствуют (она же является первым этапом при найме на полный день). Нет, мы не стали более разнообразными без усилий, многие люди проделали очень тяжелую работу по расширению нашего процесса найма и нам пришлось стать очень креативными, чтобы построить разнообразие в нашем офисе.



Та статья, ссылку на которую я только что дал – хороший пример. Когда мы хотели стать «более разнообразными» при помощи набора и обучения выпускниц из Flatiron School, мы просто это сделали, потому что нам не пришлось сначала становиться «более вмещающими».



Это было потому, что наша культура была сосредоточена на бизнесе в разработке: как ПО разрабатывается, продается и поддерживается. Если вы в восторге от этого, вы автоматически принадлежите ей. Вам не нужно задерживаться допоздна, пить алкоголь, играть в «Rock Band», играть в настольные игры, не иметь необходимость забирать детей, ходить в церковь, не ходить в церковь или делать что то еще, кроме того, чтобы работать с 9 до 5 и заботиться о выпуске хорошего ПО.



Социальные действия (пиво, «охота на пельмени», настольные игры, бег) были естественным образом отделены от работы. Ничья карьера не зависела от участия в них.



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



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



Мне тут напомнили, про идею, стоящую за «Getting to Yes» (прим. переводчика: имеется в виду книга «Переговоры без поражений» Роджера Фишера) – классической работой по переговорам. Идея в том, что на переговорах, если вы ограничиваете количество пунктов, по которым заинтересованным сторонам нужно договориться, вы увеличиваете шансы придти к соглашению. Вы отбрасываете в сторону свои желания, в пользу прихода к соглашению, просто фокусируясь на своих нуждах. Это выглядит очевидным при взгляде назад, но это действительно произвело революцию в деловом мире.



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



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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332478/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<разработка программного обеспечения - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda