3 ms·

Haha yes, you are :) What you should expect when viewing these metrics as Project Manager is to know the workflow of your engineers, not the risk associated wi

Haha yes, you are :) What you should expect when viewing these metrics as Project Manager is to know the workflow of your engineers, not the risk associated with each of the tasks. In relation to your question, the impact determines the level of involvement of each PR within the repository. Not necessarily greater impact implies greater risk, but a better quality of the task in short. In the end, what we need is data to make decisions based on something palpable.

knightofmars 7y ago
I appreciate your taking the time to respond to my inquiries. I'm genuinely curious how one is supposed to use the information your application provides. I agree with your statement, "In the end, what we need is data to make decisions based on something palpable." But the part I'm not convinced about is that the data being provided is the right data to use in making a decision. Does your response, "Not necessarily greater impact implies greater risk, but a better quality of the task in short." imply that there is a relationship between Impact and quality? I read through a number of your other blog posts and still don't have a clear understanding of what it is that a project manager (or others) should be doing with all of this information. Can you give me a use case example of how I (as a project manager) would use an Impact visualization in my decision making process? Thank you again for taking the time to answer my questions.
- alesdonoso 7y ago
  Hi there again knight! As you can imagine, we are a Startup actually consolidating our product. We are in Seed stage so every feedback we receive (like yours) makes us very happy and prouds and helps us tons! So thank you again for taking your time to ask me questions! Since we are validating some of our visualizations and insights, not all people will find the value, while others do. In our case, some of our customers are using the "Impact" visualization to gamify some way the code process with the engineers so they are more motivated and have increased the quality of their processes overall. You are probably right by saying that our provided data could be not the right data to make decisions. It will depend on you and the value you find in that information we provide. As I told you, we are validating and you are free to talk to me and write me your pains if you have them! Thanks again knight!
  - knightofmars 7y ago
    > It will depend on you and the value you find in that information we provide. First, I understand that Scope is a startup and working a lot of this out so please take my response as constructive feedback. I suspect that you're missing my point. If you're selling this product to me then you need to sell me on how it's going to make my life as project manager, CTO, or engineer better. Saying that it's data for decision making is a start. But my perception on our conversation is that every time I've tried to pin down a concrete answer on "What decisions does this help me make?" you've responded along the lines of "This is the data and this is how it's created." That's not telling me what immediate actionable steps this data will allow me to make and to make better. Subsequently, how those actionable steps will lead to more productivity and better quality. Hopefully that gets across what I was attempting to understand. Best of luck to you and Scope!
    - alesdonoso 7y ago
      Hi again knight and thanks for your response! Sorry if I misinterpreted you at some point. Of course, I fit your criticisms constructively and I have always tried to answer your questions not with the aim of saying "this is what you get, you draw the conclusions". I hope my answer is more conciliatory and you can understand our value proposition! :) First of all, Scope's sense is to help IT Managers have data. What kind of data? 1. Know the workflow of engineers: frequency of commits, pull-requests and revisions. With this data, we can know exactly the productivity peaks, the days where you work the most and the time slot where you are most productive. 2. Know the duration of the tasks: with a historical data, software factories can adjust budgets better and have a better idea of how long it can take them to finish a specific project for a client. We can see two things: the duration of tasks at the project level and at the engineer level. We help to know the evolution of time by days, weeks and months on both levels. 3. Know how the tasks are related among engineers, (this is on the roadmap, not in production). We want to throw data to know how the tasks are distributed among the engineers, how the reviews work among them, what level of involvement exists, how the workflow with the PRs improves, number of comments by type of task or by person, .. We are working on providing data that can help to better structure processes internally. With this, we want to get engineers to communicate more with each other and increase motivation and the level of involvement among colleagues. 4. Impact of the tasks. At a low, medium and high level. We establish criteria based on an algorithm (constantly evolving) based on good practices within the code: comments, revisions, affected dependencies, modified lines, labels, commit message, type of task, etc. With this, we help you understand the impact level of each pull-request in the code. We help detect talent, lack of motivation, progress from a junior to senior engineer, ... We want to connect with Sonarqube tools to really see if that impact we reflect is directly related to the technical debt in Sonarqube. And on the roadmap, there are more things. We want to make a very cool tool, and feedbacks like yours help us greatly! Once again, thanks knight! Anything, write me again!

knightofmars 7y ago

I appreciate your taking the time to respond to my inquiries. I'm genuinely curious how one is supposed to use the information your application provides. I agree with your statement, "In the end, what we need is data to make decisions based on something palpable." But the part I'm not convinced about is that the data being provided is the right data to use in making a decision. Does your response, "Not necessarily greater impact implies greater risk, but a better quality of the task in short." imply that there is a relationship between Impact and quality? I read through a number of your other blog posts and still don't have a clear understanding of what it is that a project manager (or others) should be doing with all of this information. Can you give me a use case example of how I (as a project manager) would use an Impact visualization in my decision making process? Thank you again for taking the time to answer my questions.

alesdonoso 7y ago
Hi there again knight! As you can imagine, we are a Startup actually consolidating our product. We are in Seed stage so every feedback we receive (like yours) makes us very happy and prouds and helps us tons! So thank you again for taking your time to ask me questions! Since we are validating some of our visualizations and insights, not all people will find the value, while others do. In our case, some of our customers are using the "Impact" visualization to gamify some way the code process with the engineers so they are more motivated and have increased the quality of their processes overall. You are probably right by saying that our provided data could be not the right data to make decisions. It will depend on you and the value you find in that information we provide. As I told you, we are validating and you are free to talk to me and write me your pains if you have them! Thanks again knight!
- knightofmars 7y ago
  > It will depend on you and the value you find in that information we provide. First, I understand that Scope is a startup and working a lot of this out so please take my response as constructive feedback. I suspect that you're missing my point. If you're selling this product to me then you need to sell me on how it's going to make my life as project manager, CTO, or engineer better. Saying that it's data for decision making is a start. But my perception on our conversation is that every time I've tried to pin down a concrete answer on "What decisions does this help me make?" you've responded along the lines of "This is the data and this is how it's created." That's not telling me what immediate actionable steps this data will allow me to make and to make better. Subsequently, how those actionable steps will lead to more productivity and better quality. Hopefully that gets across what I was attempting to understand. Best of luck to you and Scope!
  - alesdonoso 7y ago
    Hi again knight and thanks for your response! Sorry if I misinterpreted you at some point. Of course, I fit your criticisms constructively and I have always tried to answer your questions not with the aim of saying "this is what you get, you draw the conclusions". I hope my answer is more conciliatory and you can understand our value proposition! :) First of all, Scope's sense is to help IT Managers have data. What kind of data? 1. Know the workflow of engineers: frequency of commits, pull-requests and revisions. With this data, we can know exactly the productivity peaks, the days where you work the most and the time slot where you are most productive. 2. Know the duration of the tasks: with a historical data, software factories can adjust budgets better and have a better idea of how long it can take them to finish a specific project for a client. We can see two things: the duration of tasks at the project level and at the engineer level. We help to know the evolution of time by days, weeks and months on both levels. 3. Know how the tasks are related among engineers, (this is on the roadmap, not in production). We want to throw data to know how the tasks are distributed among the engineers, how the reviews work among them, what level of involvement exists, how the workflow with the PRs improves, number of comments by type of task or by person, .. We are working on providing data that can help to better structure processes internally. With this, we want to get engineers to communicate more with each other and increase motivation and the level of involvement among colleagues. 4. Impact of the tasks. At a low, medium and high level. We establish criteria based on an algorithm (constantly evolving) based on good practices within the code: comments, revisions, affected dependencies, modified lines, labels, commit message, type of task, etc. With this, we help you understand the impact level of each pull-request in the code. We help detect talent, lack of motivation, progress from a junior to senior engineer, ... We want to connect with Sonarqube tools to really see if that impact we reflect is directly related to the technical debt in Sonarqube. And on the roadmap, there are more things. We want to make a very cool tool, and feedbacks like yours help us greatly! Once again, thanks knight! Anything, write me again!