Se afișează postările cu eticheta Software Developer. Afișați toate postările
Se afișează postările cu eticheta Software Developer. Afișați toate postările

luni, 4 iunie 2012

[Team Velocity 5] Entry. Exit. Signs.

Leave a Comment

Copyright: Symbolgraphics.com
Any decent highway has proper traffic signs for entry and exit points. This is not new wisdom, but it is somehow astonishing how big is the difference between the theory and practice when modeling teams as highways.


I strongly believe in two of the new management ideas: enable people to act and self organizing teams. I enjoy when I see teams who share this and it would be more likely to join on of them. For each of the individuals to join a team, there is the need of orientation. People who share same values, principles, who are alike would join together. At least, this is what Cialdini promises when explaining about the six principle of influence. They would be more likely interested to join such teams or organizations when the traffic signs convey the traffic to your team and the traffic outside the team is controlled in order to not generate disruptions. The egress from such constructions should obviously be smooth in order to keep the rest of the traffic at same speed.

Let’s take one by one.

Getting traffic to your highway.


Every highway is connected to the regular roads in a systematic manner. This is my hope. Assimilate the ingress with recruiting and attracting people in your organization. Think how your highway connects the current position of the team member and his destination. Destination is unique, with tons of possible roads. I don’t want to change your destination, my only goal is to make you my partner for the part of our journeys that match together.

Speak about what you value most, what are your most valuable experiences that you can share during the journey. Put there some ideas about what makes unique a journey on your highway. Be consistent in your public expressions. Your team member will follow you and they will replicate the wisdom around. Their journeys are sometimes running on normal roads (like personal projects, family things). These roads can convey other traffic, other journeys into your highway. It's a matter of values and interests. Consistent and genuine. You are not fooled by big words. Others, neither.

Restart past collaborations

The journeys are not the same for all. But the journeys can share parts of the routes. For a while, being part of your team is not relevant for one's route. Than, it might become relevant again. There might be improvement to your highway as well, there might be changes in the destination. Anyway, you share values and the connection is somewhat made. You can imagine a faster lane, a better road, nicer vehicles on the road or best buddies

You are not static


Once I heard a saying: "Don't be irreplaceable. Thus, you won’t be ever promoted." Every manager wants to be promoted at a certain moment in time. To make a lateral change to extend his experience. It is rarely the case to have the same position over 10 or 15 years. The highway might be other, but the administrator is the same. It's personal branding that brings in traffic and conveys routes to a certain highway. Some people like you better than others. Sympathy on one hand, coming from the others. Empathy, from you to the others. Close the circle.
It's not easy to restart collaborations. The leave and returning are governed by pride, by dreams, by perception, by sentiments. It's never black or white and no one is really right. In some extend, it's a little bit like in marriage. At least, these days when management is changing slightly its paradigms.

Reasons for separation


Try to understand why people are leaving your team. There are hundreds of possibilities and you need to understand where has been the turning point. The easiest approach is to consider that nothing could have been done. It might be the case, but you still can learn how to predict these situations and prepare emergency scenarios before looking how the team member is leaving.
Don’t be hard-hearted. People are not replaceable tools or resources. Approaching professional relationships like a relation with your car prevent you to learn. Communication is bi-directional. Don’t be like a radio, broadcasting but not receiving the feedback.

Learn and improve

Every event like this is a great chance to learn and to improve. Understand; assume mistakes in case you did some. Managers are not IronMan, with an invincible steel plate. It’s more what the free gift of feedback can bring to the development of the team. Sometimes it’s the lack of attention one got. Sometimes it’s the missing opportunity to grasp. Next time could be the type of activity some is enrolled. It’s never too late to learn something new.
Don't blame the "company". There are some humans behind. This way is just passing the guilt and refusing to accept real facts. Like the state, company does not exist by itself. People are running it and they are doing specific actions that might trigger discontentment. Passing the blame to system wont make system running better. This situation does not occur in small companies. There, people know each other and don’t use these big words.

Support the progress


Be ready to shift team members to another team. Highways, at least in bigger companies, should be interconnected. Make sure that your connection to other highways is optimum and gets also some traffic back. Make sure that the entrance is always to a good lane, to a nice highway. Build competences that are meaningful in the big picture, not only in your small ecosystem. As I said in the beginning, people spread the word and this can convey traffic to your highway. When you prepare the changes, you have two huge advantages: you control the moment when a change is done and people perceive you as partner in their journeys. Great things, both!

Communication of change

It’s natural that people leave teams. Be careful how you explain this. Don’t hide it. Don’t blame the guy who is leaving. Explain, as transparent as possible, the reasons and the context. Insist on context. If you are not an asshole, the context is important in such a change.  What is relevant for one might not be for another. When hiding the situation, people have the tendency to start making assumptions. Even when situation is not in your favor, you can turn into a positive fact by admitting a mistake and show the improvement plan.

 Trust

Trust the one who are actually leaving the team. Their route is now changing. They can even contribute from outside with opinions, lobby or just to spread the word about what great things you accomplished together.  Showing trust, you just gained more respect from people working with you. They can expect this behavior more as they are with you. People are not static; you will meet them sometimes in the future. This is another idea to bear in mind.

Every day prepare the future and work hard that the present is the future you prepared yesterday.

Read also

Team velocity [1] - the idea
Team velocity [2] - the relation between the mission of the team and its velocity
Team velocity [3] - The entry points on the highway
Team velocity [4] - The exit points from the highway


Read More...

vineri, 11 mai 2012

Campionii, Campionii!!! OLE, OLE, OLE

Leave a Comment
Cititi un reportaj tulburator despre succes, adaptabilitate, competitie, intoarcerea la parinti si prieteni...


"Cum mai sînt americanii? În realitate vreau să spun, nu în filme.
A: - Sînt crescuţi în spiritul acela de a şti că totul depind de tine, nu de ceilalţi. Dacă nu ai ajuns bine, eşti educat să pricepi că a fost vina ta, că societatea nu îţi datorează nimic."

- Ce continuă să nu vă placă în România?
- Sîntem obişnuiţi să aşteptăm, sîntem lipsiţi de speranţă. Văd oameni tineri convinşi că fără pile nu se poate. Cum au ajuns să-şi dea seama de asta la 20 şi ceva de ani?!


GAZETA SPORTURILOR
Read More...

duminică, 1 aprilie 2012

Programatori, suntem niste rasfatati!

1 comment
[Update 17 Apr 2012] Am gasit articolul lui Joel Etheread, care sumarizeaza mai multe puncte de vedere care il sustin pe Ionel Condor.

[Update 2 Apr 2012] Dupa comentariul lui Ionel, am schimbat titlul. Mi se pare mult mai relevant acu. Si am trecut la persoana intai plural. Asa suntem noi, programatorii. In definitiv, titlul initial al blogului a fost despreprogramatori.blogspot.com

Ieri, dupa cum ati citit unii dintre voi deja, am participat la Open Agile Iasi. Unul dintre speakeri, Ionel Condor, a spus la un moment dat ca programatorii sunt rasfatati.
Corect, suntem niste rasfatati. Avem intotdeauna de ales intre 2-3 optiuni de job, suntem valorizati in companiile lor noastre, li  ni se vorbeste frumos si li ni se ofera posibilitati de dezvoltare personala. Toate bune si in regula pana aici.
Problemele pot aparea, asa cum au aparut pentru agentii imobiliari, atunci cand se opreste cresterea. Cine e pregatit sa creasca si pe vremuri in care industria nu creste? Cine poate sa se reinventeze atunci cand tehnologia in care este specialist nu se mai cauta in aceeasi masura? Cine poate sa lucreze, la 45 de ani, avand acelasi entuziasm ca si la 30?
Cumva, ma pot gandi la copiii cu parinti bogati, care au de toate in adolescenta si tinerete, iar apoi sunt nevoiti sa infrunte consecintele unui faliment. Nu toti revin la pozitia anterioara....
Read More...

duminică, 22 ianuarie 2012

Necesitatea metodelor in dezvoltarea de software

1 comment

Unul dintre hobby-urile mele este sa gatesc (nu, blogul ala nu e al meu). Fac asta din cand in cand, nu destul de des sa pot sa va invit la masa, dar destul incat sa repet retetele de cateva ori.

Inainte de Anul Nou obisnuiesc sa fac cornulete impreuna cu fiul meu. El se distreaza, eu ma bucur de o companie grozava in timp ce imi practic una dintre pasiuni. Zis si facut! Doar ca am observat ca nu imi ies bine cornulete in ceea ce priveste forma. Nu seamana neam cu cele facute de o patiserie sau cele pe care le pot gasi in magazin. La gust sunt bune, dar nu ma descurc sa le fac la fel de bune ca mama.
M-am intrebat ce imi lipseste ca sa am succes. In principiu, sa fii barbat si sa gatesti iti ofera ceva prilej de conversatie cu prietenii, o mancare pe gustul tau (daca reusesti sa te descurci pana acolo) si un pic de apreciere din partea doamnelor (vedem ce putem face cu asta mai tarziu). Dar eu imi doresc in continuare sa imi iasa beton cornuletele.

Intre doua pahare de bere (de!, barbatii au si alte pasiuni in afara de gatit), am inceput sa analizez ce nu merge. Am descoperit ca nu aveam un design prea bun. Foaia de aluat avea o forma neregulata, iar grosimea nu era uniforma. Nici implementarea nu era prea uniforma. Adica taiam bucati mai mici sau mai mari, cornuletele aveau volume diverse si aratau foarte eterogen.  Si ma gandeam cat de important ar fi fost sa am o metoda de a le face foarte asemanatoare. De fapt, sa pot prezice cum vor arata si cat vor fi de mari sau de mici.

Apoi, din deformatie profesionala, mi-am dat seama ca un anume fel de a face lucrurile (a se citi metode) ajuta in predictibilitatea rezultatului. Bineinteles, exista doua componente in a face prajituri. Gustul si aspectul. Gustul este influentat de oameni in mod diferit, dar forma poate fi usor reprodusa. In mod normal, prajiturile gustoase, dar cu un aspect neregulat nu au aceeasi vandabilitate ca si cele foarte aspectuoase.

In consecinta, am tras o concluzie pentru mine: o organizatie care isi defineste metode de dezvoltare pe baza experientelor anterioare isi maximizeaza sansele de a produce software de calitate. Motivul principal este ca oamenii pot pune la lucru creativitatea si inovatia, pe fondul unei performante constante asigurate de o metoda. In final, un proces de dezvoltare, fie el clasic sau agile arata maturitatea unei organizatii si sustine performanta. Altfel, produsele vor fi inegale, la fel ca si cornuletele mele.

Mai jos am adaugat si o caricatura celebra referitoare la dezvoltarea de produse software.
Read More...

miercuri, 4 ianuarie 2012

Programatorii adopta culturi organizationale mai greu decat cei din alte meserii?

Leave a Comment
August 2011:
Programatorii adopta culturi organizationale mai greu decat cei din alte meserii?
Sunt artisti sau ingineri?
Ii putem asimila arhitectilor sau inginerilor constructori?

Intrebari. Raspunde cineva?

Ianuarie 2012:
Nu a raspuns nimeni. Concluziile mele sunt ca o cultura organizationala se adopta cu atat mai greu cu cat creativitatea echipei este mai crescuta. Ca o contrapondere, culturile organizationale sunt cu atat mai solide cu cat creativitatea echipei este mai crescuta. Adoptia principiilor este mai constienta si mai buna.
Read More...

vineri, 2 decembrie 2011

despre programatori

1 comment





De la http://www.facebook.com/pages/I-am-ProgrammerI-have-no-life/241806149201604
Read More...

miercuri, 30 noiembrie 2011

UML in embedded (II)

1 comment
Here we go again.
I had a short talk today on how to document design.
I make now a short resume of the ideas.
All designs needs to document (from a perspective of a single software component) two main areas:
- static description
- behavioral description

For the first one, you need to imagine what is the layout of your SW Component (functions, variable, global or not). Let's call this class diagram. Additional, you have to catch in one picture which are the provided interfaces and which are the required interfaces. Let's call this component diagram.
If you imagine an engine, until now you depicted the size, shape and how the engine can be mounted in the car.
Then, please think about the behaviour of the SW component.
Imagine some scenarios based on use cases. This can be depicted using sequence diagrams.
Go further and describe special algorithms via activity diagrams.    Don't use for each and every flow, it makes it only hard to read.
If you model your system based on states, don't forget state machine diagrams. Here, there is plenty of literature to read about modeling system based on state machine diagrams.

Here you go, takes this steps and try to document your work. Jack Ganssle makes a nice review on a new book, about documenting software. It goes in the idea of writing beside code. Al Stavely’s new book, “Writing in Software Development,”

I will come up next month with some ideas about how to mix Doxygen and tools like UMLet to make nice documented SW components.

Read More...

sâmbătă, 5 noiembrie 2011

Estimations (not agile)

Leave a Comment

Why are needed?
Simply because you also need a deadline from your builder when the house is finished. And for sure, you ask for a delivery date when you go to your tailor. Plus, you ask for a price. No deal is closed without a price indication and a delivery date.

Simple tricks to make it better:
1. Read down what you have to do
2. Understand it
3. Split it in pieces.
4. Write down the pieces and think how much would you spend for each.
4.a. You have do in it and can look back in the history. Put the figures there.
4.b. This is the first time you have to do this. Split it in more pieces and go back to step 4.
4.c You cannot escape from step 4.b. Use your intuition. How complicated does it seems?
                        Same other task : put the same effort as for that, plus the learning effort
                        Twice as complicated: twice the effort plus the learning effort.
                        Five time as complicated than what you did so far: ask for another task.
5. Think a little about risks: what can happen to prevent you for completing the task. Put some effort there (not for all risk you identify, only for half of the big ones).
If the risks are to high, ask for another task or tell this to manager.
6. Sum it up and see if you can reach the deadline.
If this is not possible, then see what is the delta missing: can you speed up and delivery in time or is basically impossible and should tell this to the guy who requested this.


Read More...

UML in embedded (I)

Leave a Comment
I say now a truism. Model based development will be the new quantum leap in software development in terms of productivity.
It surely takes more years to adopt UML in the development, but there is a clear path to this.

Some directions:
  • code generation (hard constraints) and documentation.
  • UML meta models are the basis of AUTOSAR standards. AUTOSAR is heavily supported by most of car manufacturers.
  • UML and re-use of software should be good friends.
  • Round trip engineering tools are more and more available for embedded and ease the re-use, as the design documents are more readable.
More post on this in the near future.
Read More...

luni, 31 octombrie 2011

Application development vs Kernels and drivers development

Leave a Comment


When speaking about how to develop software, one is usually making the difference between drivers, OS and rest of the application software.
It is always about different strategy in developing the software. The lower software layer have to be generic, scalable and easy to use, if possible. The developer is applying some paradigm, even defined by the OS itself and has to optimize the usage of the hardware. The primary customer of his application is the colleague next to him who will develop further the application


The application has slightly different constraints. It has to meet the expectations of the customer, as well as to implement non-functional requirements. Now, the customer is identified and the generic cases are not in the focus. One can argue that re-use of software is a trend now. A trend yes, but a primary focus very seldom.

Then, it is the pressure of delivery date. The generic development has some buffers in the timescale. The application has to meet the delivery date to customer. This is not easy to negotiate and it is part of the product to be delivered. The generic software is part of a strategy. We start early, it is nothing yet defined and there is no recipe how to do it.

This fight with uncertainty combined with the scarcity of information in what regards the new technology is giving the developers of basic software this aura of pioneers or medieval knights who are pushing the limits. The others, as harsh it might seem, are actually the bourgeois who are the core of society and they are keeping where there are the existing limits.
Read More...

joi, 20 octombrie 2011

Democracy in software engineering?

Leave a Comment
Article first published as Software is Democratic on Technorati.

Maybe you have read "Funky Business". Two Swedish professors, Jonas Ridderstrale and Kjell Nordström. are writing about how information open more opportunities for less developed countries.
Internet access is cheap, the need for application is great and the offer is high. The quality can vary, but this happens in all the cases, no matter the origin of the author. Now, the most significant competitive advantage is the intelligence of the software engineer.
The engineering is democratizing in what regards software. With a decent speaking of English, a decent internet connection and anyone can challenge the old markets. MIT is publishing courses on their website Many other universities do the same. Internet is full of tutorials and courses. So the information is easy to grasp and use at will
One can argue that you need licenses for the tools. This is partly true. On one hand, there are plenty of frameworks for free. You need a few bucks to be able to publish apps on Apple Store. Or the well known platforms of download, where you can offer your products.
As well, the pressure from emerging markets can be seen in highly specialized markets. Telecom, automotive electronics are now produced all over the world. The development locations are spread in the same way. A few months ago, Bosch opened a new development center in Vietnam. How do you find this? I find it as a natural step to globalization.
The funny thing is that salaries in developed countries are not going down, even with this equality of chances. This is, IMHO, due to large increase in demand of applications. Suddenly, you can sell thousands of applications on web stores. Nevertheless, compared to 10 years ago, I do have at least 5 devices which embed software. The new TV set I would like to buy has even WiFi included. My fridge has a complicated algorithm of freezing. The oven can be set in all kind of programs. I don't have an iPhone. Still, my phone has internet connection, camera and calendar included. I expect that average gadgets do have more lines of code than AppleII computer.

So, there is room for everyone. The next thing will be to transfer all this programming mindset from single processors to multiprocessors. Let's see how this will change the world.
Read More...

marți, 18 octombrie 2011

Unit test

Leave a Comment
Do programmers test? If yes, do they think that testing is somehow dishonoring them?
Do great programmers have a great testing technique? YES.

I noticed that most of the programmers hate to test their work before integration in a bigger product.

I will come back to testing, attitude and tools.
Read More...

duminică, 9 octombrie 2011

A good analysis of Iasi market for programmers

Leave a Comment
Andrei Ciubotaru is making a good analysis of Iasi market on his blog
It's also a little bit of self advertisement, but I reckon really good information there for the possible investors.
Read More...

miercuri, 5 octombrie 2011

Embedded is not dead. It is very much alive and growing.

Leave a Comment
Michael Barr is a columnist and embedded guru, hosting a newsletter and organizing Embedded Software Boot Camp.
He posted today a special issue of the newsletter, looking to the growth of embedded sector in U.S. My impression is that embedded is not dead at all not only in US, but also in Europe and Asia. Looking back to one of the older posts, I can tell you that nowadays these engineers are hard to get. 
My friends working in Europe constantly get phone calls from agency with plenty of vacancies. I know some companies that are able to fill their positions not earlier than 6 months. Speaking now only about embedded sector.
I am joining the idea of Michael Barr and I will create a section with possible job offers coming from companies who would like to hire in Romania these kind of profile. In case someone is interested, please send an email.


PS: Don't lough, maybe I am ridiculous with this initiative. This is only a little step to help the industry where I make a living (in Romanian, I could say "mananc o paine alba)".
Read More...

joi, 22 septembrie 2011

Cultura organizationala (II)

Leave a Comment
Programatorii adera mai greu la o cultura din pricina parerilor puternice pe care le au, de obicei. Fiecare creator de software isi asuma paternitatea ideilor si sunt mai opaci la adoptarea uniforma a unor principii.
Poate aceasta este una din caracteristicile unei culturi organizationale pentru organizatii de ingineri programatori.
O alta nuanta vine din timpul de adoptare si cine impinge adoptarea unei asemenea culturi. In functie de distanta de putere dintre manager si ingineri, in functie de numarul de oameni care adopta activ aceasta cultura, cultura organizationala este traita sau pictata in PPT-uri.

Citeste si :
Cultura organizationala ( I )
Read More...

vineri, 9 septembrie 2011

How many and which changes should a freshman do?

Leave a Comment
A fresh graduates brings with him dreams. Not all dreams may come true.
Some of the dreams even does not have to come true.

How to decide which ones are worth to be lived and which not? A little thinking and some try and error.
There are two types of try and error. When you try big and you can make a difference and when you try small and don't risk to much.
Depending on your personality, you can assume the risk to try big and have a quantum leap. You dont think too much, simply you implement your dream!
Or, you take a small instance of your dream and try to apply in a controlled environment. Then, you can make an analysis and decide.
So, if you are an young programmer and you would like to make a change, think for a moment which type are you. If you can cope with risk and failure quite well, than try big changes. Even you are tough guy, don't do it so often. Imagine the context switching lag in your life, you might loose too much time in context switching.
If you are a guy who really likes to plan his life, than think twice and experiment without changing everything at once.

See you in next assignment!
Read More...

marți, 6 septembrie 2011

Pipelines (Conductele)

Leave a Comment
  • Cat de lungi sau scurte sunt ciclurile de viata ale unei echipe?
  • Cum este legat ciclul de viata al unui produs de ciclul de viata al unei echipe?
  • Cand trebuie reinventata echipa si cand trebuie reinventat produsul?

Nimeni nu poate prevedea cu exactitate ciclul de viata al unei echipe. Cele 4 faze in inchegarea unei echipe iti pot da o indicatie destul de buna despre cand ajung la apogeu. Fazele despre care vorbesc sunt Forming, Storming, Norming, Performing. Tuckman a fundamentat aceasta teorie inca din 1965 (vezi Wikipedia)

In principiu, nu am vazut oameni ce nu se cunosc in prealabil si care sa formeze o echipa intr-un interval mai mic de 6-9 luni. Oamenii care nu sunt intr-o echipa, ci sunt parte a unui grup in prealabil pot, probabil, duce intervalul la 4-6 luni.
Echipele competitive se aseaza intr-un an, cel mai probabil.

Dupa faza Performing, o echipa va atinge nivelul de platou pentru o vreme. Acolo performeaza excelent, pentru o perioada mai lunga sau mai scurta Apoi performanta scade, din pricina intereselor divergente ale membrilor ei. Cu cat interesele converg mai mult timp, cu atat performanta va ramane ridicata.
Eu aseman aceasta stare cu o conducta. In momentul in care performerii excelenti vor dori sa faca o schimbare, echipa are nevoie de oameni la fel de motivati, cu potential la fel de bun, care sa le ia locul. Daca in echipa este alimentata cu oameni foarte motivati inainte de vreme, atunci se creaza o stare de tensiune care nu este benefica. Daca cei mai buni nu isi gasesc o alta provocare, atunci cei care vin din urma nu se pot exprima.

Functionarea instalatiilor de apa se bazeaza pe cateva legi simple. Presiunea, viteza de curgere si densitatea lichidului sunt valorile care influenteaza aceasta functionare. Daca asimilam presiunea cu numarul celor care au potential foarte bun si sunt noi in echipa, densitatea lichidului cu valoarea echipei si dorinta de a evolua in joburi noi, iar viteza de curgere cu ciclicitatea unor proiecte si momentele in care pot iesi din rol unii din membrii echipei, atunci putem caracteriza o echipa si evolutia ei.
Read More...

luni, 1 august 2011

Interviuri cu ingineri (2)

Leave a Comment
Promiteam in urma cu ceva timp ca voi publica din invataturile pe care le-am tras din sesiunea de angajari de anul acesta.

Ce pot sa spun:
- oamenii talentati fac diferenta in proiecte;
- nu se poate sa faci o echipa numai din oameni de tip "out-of-ordinary". E o tautologie, dar e lucrurile evidente nu sunt aplicate intotdeauna.
- este dificil sa astepti pentru "perfect fit". Compromisurile, in schimb, trebuie sa fie acceptabile pentru echipa.
- angajarile ar trebui facute, ca la sah, cu 2-3 mutari inainte. Adica, sa consideri si urmatoarele posibile 2-3 insarcinari, fie tehnic, fie de management.
- cei care sunt deja "on board" fac cele mai bune recomandari in momentul in care sunt responsabilizati. Chiar mai mult, daca se simt parte din decizie.
- nu intotdeauna cel mai bun om este cea mai buna alegere pentru un job. Cel mai potrivit este cel care se integreaza cel mai rapid si ofera cele mai bune rezultate pe termen scurt si mediu.
- daca te astepti sa aiba efect efectul Pygmalion, chiar functioneaza.
- nu accepta primul NU dupa o oferta. accepta-l intotdeauna pe al doilea.
Read More...

joi, 2 iunie 2011

Din nou despre sport si echipe

Leave a Comment


Talent.
&
Echipa.
&
Stiluri de joc.
&
Motivatie.
=
REZULTATE.

Din nou, o postare in formatul caracteristic.
Nu poti sa disconsideri, in orice afacere te-ai afla, influenta majora a talentului in rezultatele unei echipe. Am auzit si chiar am aplicat, din pacate, formule simpliste in care un om poate fi inlocuit de alt om in orice pozitie a echipei. Sau, ca doua proiecte sunt similare.

In opinia mea, orice echipa incepe macar cu un talent care se extrage din multimea oamenilor. Orice proiect de succes, orice idee trebuie sustinuta de o suma de talente care este egala sau mai mare decat 1.
Managementul talentului reprezinta o suita intreaga de teorii. Cum sa il atragi (de ce sa intre un om deosebit in echipa ta?), cum sa il dezvolti (fiecare talent, chiar si cele mai mari, trebuie slefuite), cum sa il motivezi (de ce sa imi pun tot talentul in echipa ta?) si cum sa il tii conectat la echipa respectiva (este talentat, deci e foarte posibil sa fie destui care sa il remarce si sa incerce sa il coopteze in echipa lor). Nu am citit destul pentru a teoretiza, dar cred ca orice afacere (mai mica sau mai mare) trebuie sa aiba grija de talentele pe care le atrage. Acum voi face si paralela cu sportul. Un tip talentat poate fi baza unei echipe de succes. Voi da un exemplu fumat, dar sugestiv: Gheorghe Hagi. A fost baza echipei din 1994. Pare sa fi fost un succes.

Dar un tip talentat nu este de ajuns. Este necesara o echipa in jurul lui. O echipa unita, care sa lucreze in aceeasi directie. Ce s-ar intampla daca echipa din jurul lui nu ar sustine talentul respectiv? Probabil ce s-a intamplat la Dinamo anul trecut (in 2010-2011). O echipa care l-a continut pe unul din cei mai buni jucatori din campionat (Torje), care a avut unul din cele mai bune atacuri, nu a reusit sa incheie mai sus de locul 6. Indeajuns de prost pentru a fi catalogat ca un esec. In schimb, Otelul Galati, o echipa fara vedete deosebite in teren, cu doua talente in zona management (Marius Stan) si antrenorat (Dorinel Munteanu) a reusit, contrar tuturor asteptarilor, sa devina campioana. Echipa conteaza. Echipa acopera imperfectiunile fiecaruia. Echipa ajuta sa mergi mai departe cand esti obosit, sau demotivat sau nu stii ce sa faci.

Nu exista o reteta a echipei. Conteaza cine este in echipa. O sa numesc asta stiluri de joc. Exista echipe formate in jurul unui singur om, care se prabusesc atunci cand acesta nu mai are energia de a duce echipa mai departe. Exista echipe ce sunt formate si raman pe loc. Performeaza foarte bine, au rezultate. Dar ii gasesti in acelasi format si peste 3 ani. Asta inseamna ca roluri si performanta. Exista echipe in care oamenii se completeaza si se dezvolta unii pe altii. Echipele acestea apar ca un fractal. Acestea dezvolta interior motivatia de a progresa.

Motivatia poate face de multe ori diferenta intre o echipa medie si o echipa extraordinara. Daca fiecare membru stie de ce face ceea ce face si ca impreuna gasesc o motivatie de a realiza un proiect sau business, atunci e o echipa de vis. Managerul unei asemenea echipe nu are nevoie sa verifice in detaliu. Nu ii este frica si nu are nevoie sa isi acopere spatele. Motivatia este acolo. Oamenii au succes si intra in cercul vicios pozitiv. Produc REZULTATE la rand.

Am citit de curand despre succesul Barcelonei cu LaMasia. The Economist a publicat un articol despre successul lor. Este tradus si in romana de Money Express. Ei vorbesc despre ideea de echipa si modul in care acest lucru este educat de la cea mai frageda varsta.

Enjoy!
Read More...

sâmbătă, 29 ianuarie 2011

Interviuri cu ingineri

3 comments
Revin, dupa mai bine de un an cu inca un post...


De cand ma ocup de o echipa de embedded software engineers, am facut multe interviuri si am vazut diverse tipuri de oameni. Unii sunt interesati de bani, altii de o cariera, dar sunt destul de multi preocupati sincer de "software engineering". Nu sunt programatori doar. Vor sa vada o solutie care merge.
Dintre ei, majoritatea se apuca sa mestereasca la o placuta in anul doi sau trei de facultate, se invart pe langa un profesor cu pasiune si in timpul liber. Apoi, fie se duc pe la concursuri studentesti, fie se angajeaza inainte sa termine facultatea, dar merg in continuare pe directia respectiva.
Peste 3-4 ani, ii gasesti de obicei ca oameni de baza in proiecte, stiu cam cel mai bine ce vor si ce ii face fericiti si sunt relativ mai relaxati decat colegii lor.
Ipoteza mea este ca le face placerea munca lor si nu trebuie sa ajunga acasa pentru a se consacra hobby-ului. Cred ca ei sunt cei care vin cu idei, care schimba si felul de a face lucruri in firmele in care lucreaza.

Am mai multi colegi de felul asta si e o placere intotdeauna sa lucrez cu ei.

Au contraire, exista si multi tipi cu mare potential care nu inteleg ce vor sa faca cu viata lor. Incep fulminant diverse insarcinari, par a sparge normele si deodata ceva se infunda. Contesta organizatia din care fac parte, dar nu propun solutii concrete. Nu sunt atasati emotional de echipa, sunt mai multi purtati de o noua idee. E surprinzator sa ii vezi cum ajung sa bifeze cateva esecuri la rand, pare a fi cum ai vedea un BMW M5 ca nu poate depasi un Logan si mai scoate si o gramada de fum.

E foarte dificil sa imi dau seama care s-a nascut talent si va muri speranta, dar acum cred ca e un criteriu foarte important in decizia de angajare. Cel putin la fel de important ca si cunostintele curente...

Promit ca peste 6 luni va voi povesti mai multe despre tura de angajari pe care trebuie sa o fac anul asta si ce am invatat despre asta.

Luna viitoare voi scrie cateva randuri despre cele doua modele de business in software-ul romanesc: productie si lohn(sau outsourcing).
Read More...