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

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

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

SCRUM — мощная структура, но нам она не подошла

Должен признать, что мы не следовали Руководству по Scrum буквально. Мы не всегда вовремя проводили обзор спринта, не всегда проводили ежедневные встречи или сообщали о своем прогрессе. Так как наша команда состояла из студентов и преподавателей с разными и очень плотными графиками, нашим основным средством коммуникации был slack, где мы также проводили наши ежедневные встречи.

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

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

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

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

Выберите методологию (или структуру), которая лучше всего подходит для вашего проекта и команды.

Выскажите свое мнение

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

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

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

Если вы считаете, что что-то нужно сделать или что кто-то что-то делает не так, просто скажите об этом!

Спрашивайте о том, чего не знаете

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

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

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

Всегда спрашивайте, чего вы не знаете. Все новое, что вы узнаете, всегда полезно.

Любые конфликты между вашими товарищами по команде следует решать как можно быстрее

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

Очевидно, это также повлияло на наше общение и энтузиазм в отношении работы и, следовательно, повлияло на нашу работу. Обычно нам приходилось дорабатывать детали наших компонентов, чтобы решить эту проблему.

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

При работе в команде ваше общение, гармония и отношение имеют решающее значение для преемственности.

Не бойтесь своего клиента

Одной из основных причин неудач программных проектов является плохой сбор требований, и это, на мой взгляд, может происходить по трем основным причинам:

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

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

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

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

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

Цените свое время и усилия

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

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

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

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

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

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

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

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

Я действительно увлекаюсь машинным обучением и искусственным интеллектом, и мне не терпится написать об этом много, но до тех пор просто продолжайте писать код!