Блог
Работа. Мартышки – телепаты.
2012-07-21 10:04:37
За последнее время накопилось много мыслей, связанных профессиональной деятельностью. И чтобы они не пропали зря, решил написать этот пост и немного рассказать об организации работы в команде. Я не открою ни чего нового. Всё уже давно написано, и разжевано в умных книгах и на разных сайтах по организации рабочего процесса. Просто расскажу свое субъективное видение происходящего.
{--picfiledir/martishka.jpg** Мартышки --}
Говорят, труд сделал из обезьяны человека. Я бы уточнил - совместный труд. В нашей компании начался новый проект. Не буду описывать его назначений и особенности. Скажу только, что это будет довольно большой веб-сервис. Команда состоит из 3-х человек: я, моя коллега и руководитель команды. Все примерно одного возраста. Вообще это первый мой опыт работы в команде, поэтому многое для меня было не понятно.
Нам с коллегой сказали прочитать ТЗ. Врят ли обычный смертный или непосвященный человек смог бы понять что к чему там. Когда нас спросили всё ли понятно, мы немного помявшись ответили ДА, в надежде что походу разберемся. В общем мы начали. Но «начали» - мягко сказано. Это было похоже на тараканьи бега. Когда поднимают стакан, а они вместо того чтобы бежать к финишу разбегаются кто куда. У всех своё представление как надо делать. Иногда мы писали одни и те же участки кода одновременно, а потом оказывалось, что это уже кто то сделал. Описывали функционал, который должен был работать совсем по-другому. В общем, все старались кто как мог и в меру своих возможностей. Руководитель тоже не вносил в этот хаус особого порядка. После проверки обнаруживалось, что мы сделали это не так и нужно это переделать, как он считает правильным. А так как мы только начали работать вместе, то ни как не могли сделать всё с первого раза, некоторые участки переписывали по 3 раза. Постепенно хаос упорядочивался, и наша команда приобрела следующий вид: 2 мартышки, которые только писали код, и генератор случайных идей. При чём мартышки должны были максимально верно угадывать новою идею, иначе им говорили что они плохие мартышки и ни чего делать не умеют. Такой ужас продолжался несколько дней. В итоге приматы взбунтовались. Мы всей командой, если так можно было её тогда назвать, засели в конференц зале и стали выяснять отношения. Высказали что кому не нравится и у кого какие претензии. Основное требование мартышек было отмена неопределённости и гласность планов по проекту, дабы они могли ориентироваться под какие условия писать функционал приложения. В то время видением проекта и его логикой владел только руководитель, а он не очень любил этим всем делиться. Это были напряженные заседания. В итоге у нас наладился диалог. Мы решили собираться каждый день и обсуждать у кого какие вопросы, а руководитель обещал делиться своим знанием по проекту.
После этого дело пошло в гору. Мы стали лучше координировать свои действия. На ежедневных собраниях выделились три основных вопроса: кто что сделал, что дальше делать, и кому чем помочь. Это очень помогло, учитывая что приближался дедлайн и мы должны были вскоре выложить первый релиз. Наша команда эволюционировала из стаи мартышек в первобытное общество, где её члены договаривались между собой с целью достижения общего блага. Не смотря не на что, мы всё успели к сроку. А самое главное – наладили диалог друг с другом и руководителем. Это был большой опыт работы в команде. Для себя я сделал следующие выводы:
- перед началом любого проекта руководитель должен собрать команду и рассказать своё видение (назначение проекта, способ реализации, применяемые технологии и инструменты), потому что какое бы хорошее ТЗ не было, всё равно у каждого свое представления о различных вещах;
- нужно завести общие договоренности по стилю программирования и обозначения переменных, это очень помогает при чтении и понимании кода коллег;
- по возможности максимально разделять задачи для членов команды, чтобы не возникало путаницы и не писался дважды один и тот же функционал;
- должна быть мотивация, не важно будут ли это дедлайны, или шоколадки за успешное выполнение задач, главное чтобы был какой то внешний раздражитель заставляющий работать усердней;
- давать разработчикам волю в реализации, это связано в некоторой степени с предыдущим пунктом, потому что отсутствие творческого элемента делает работу скучной и сводит на нет все мотивации;
- должно быть максимум общения в команде, это способствует сплочению в коллективе, а также упрощает разработку продукта и повышает его качество.
Конечно, все люди разные, и в каждом конкретном случае должны быть свои подходы, но последний пункт я считаю наиболее важным. Благоприятная обстановка в коллективе зачастую равносильна хорошей зарплате.
Почти про все из этих пунктах я читал раньше, или слышал от коллег, но успешно забыл или не придавал этому значения. Мы учимся только на своих шишках. На этом я сегодня закончу. Буду стараться держать вас в курсе эволюции нашей команды и выкладывать новые посты. Так что заходите, читайте. ;)
За последнее время накопилось много мыслей, связанных профессиональной деятельностью. И чтобы они не пропали зря, решил написать этот пост и немного рассказать об организации работы в команде. Я не открою ни чего нового. Всё уже давно написано, и разжевано в умных книгах и на разных сайтах по организации рабочего процесса. Просто расскажу свое субъективное видение происходящего.
{--picfiledir/martishka.jpg** Мартышки --}
Говорят, труд сделал из обезьяны человека. Я бы уточнил - совместный труд. В нашей компании начался новый проект. Не буду описывать его назначений и особенности. Скажу только, что это будет довольно большой веб-сервис. Команда состоит из 3-х человек: я, моя коллега и руководитель команды. Все примерно одного возраста. Вообще это первый мой опыт работы в команде, поэтому многое для меня было не понятно.
Нам с коллегой сказали прочитать ТЗ. Врят ли обычный смертный или непосвященный человек смог бы понять что к чему там. Когда нас спросили всё ли понятно, мы немного помявшись ответили ДА, в надежде что походу разберемся. В общем мы начали. Но «начали» - мягко сказано. Это было похоже на тараканьи бега. Когда поднимают стакан, а они вместо того чтобы бежать к финишу разбегаются кто куда. У всех своё представление как надо делать. Иногда мы писали одни и те же участки кода одновременно, а потом оказывалось, что это уже кто то сделал. Описывали функционал, который должен был работать совсем по-другому. В общем, все старались кто как мог и в меру своих возможностей. Руководитель тоже не вносил в этот хаус особого порядка. После проверки обнаруживалось, что мы сделали это не так и нужно это переделать, как он считает правильным. А так как мы только начали работать вместе, то ни как не могли сделать всё с первого раза, некоторые участки переписывали по 3 раза. Постепенно хаос упорядочивался, и наша команда приобрела следующий вид: 2 мартышки, которые только писали код, и генератор случайных идей. При чём мартышки должны были максимально верно угадывать новою идею, иначе им говорили что они плохие мартышки и ни чего делать не умеют. Такой ужас продолжался несколько дней. В итоге приматы взбунтовались. Мы всей командой, если так можно было её тогда назвать, засели в конференц зале и стали выяснять отношения. Высказали что кому не нравится и у кого какие претензии. Основное требование мартышек было отмена неопределённости и гласность планов по проекту, дабы они могли ориентироваться под какие условия писать функционал приложения. В то время видением проекта и его логикой владел только руководитель, а он не очень любил этим всем делиться. Это были напряженные заседания. В итоге у нас наладился диалог. Мы решили собираться каждый день и обсуждать у кого какие вопросы, а руководитель обещал делиться своим знанием по проекту.
После этого дело пошло в гору. Мы стали лучше координировать свои действия. На ежедневных собраниях выделились три основных вопроса: кто что сделал, что дальше делать, и кому чем помочь. Это очень помогло, учитывая что приближался дедлайн и мы должны были вскоре выложить первый релиз. Наша команда эволюционировала из стаи мартышек в первобытное общество, где её члены договаривались между собой с целью достижения общего блага. Не смотря не на что, мы всё успели к сроку. А самое главное – наладили диалог друг с другом и руководителем. Это был большой опыт работы в команде. Для себя я сделал следующие выводы:
- перед началом любого проекта руководитель должен собрать команду и рассказать своё видение (назначение проекта, способ реализации, применяемые технологии и инструменты), потому что какое бы хорошее ТЗ не было, всё равно у каждого свое представления о различных вещах;
- нужно завести общие договоренности по стилю программирования и обозначения переменных, это очень помогает при чтении и понимании кода коллег;
- по возможности максимально разделять задачи для членов команды, чтобы не возникало путаницы и не писался дважды один и тот же функционал;
- должна быть мотивация, не важно будут ли это дедлайны, или шоколадки за успешное выполнение задач, главное чтобы был какой то внешний раздражитель заставляющий работать усердней;
- давать разработчикам волю в реализации, это связано в некоторой степени с предыдущим пунктом, потому что отсутствие творческого элемента делает работу скучной и сводит на нет все мотивации;
- должно быть максимум общения в команде, это способствует сплочению в коллективе, а также упрощает разработку продукта и повышает его качество.
Конечно, все люди разные, и в каждом конкретном случае должны быть свои подходы, но последний пункт я считаю наиболее важным. Благоприятная обстановка в коллективе зачастую равносильна хорошей зарплате.
Почти про все из этих пунктах я читал раньше, или слышал от коллег, но успешно забыл или не придавал этому значения. Мы учимся только на своих шишках. На этом я сегодня закончу. Буду стараться держать вас в курсе эволюции нашей команды и выкладывать новые посты. Так что заходите, читайте. ;)